From: Richard Henderson <rth@twiddle.net>
To: Christoph Lameter <cl@linux-foundation.org>
Cc: Rusty Russell <rusty@rustcorp.com.au>,
Ingo Molnar <mingo@elte.hu>,
akpm@linux-foundation.org, torvalds@linux-foundation.org,
andi@firstfloor.org, ak@linux.intel.com, sfr@canb.auug.org.au,
travis@sgi.com, linux-kernel@vger.kernel.org
Subject: Re: [patch 2/8] compiler-gcc.h: add more comments to RELOC_HIDE
Date: Thu, 15 Jan 2009 15:15:01 -0800 [thread overview]
Message-ID: <496FC375.90408@twiddle.net> (raw)
In-Reply-To: <Pine.LNX.4.64.0901151428020.28153@quilx.com>
Christoph Lameter wrote:
> On Thu, 15 Jan 2009, Rusty Russell wrote:
>
>>> The cast should cause the C compiler to drop all assumptions about size.
>> No, and that's the point. Sorry, at this point you need to talk to a gcc expert. As I have said, I did and I believe what he told me.
>
> The gcc expert that created this measss is cced on this thread and so
> far he not spoken up. Richard?
It has been a long time, and I don't recall all of the assumptions
involved from the time.
It was probably a combination of object size assumptions, as well as
problems with relocations. Stuff like "int foo" is known to be
allocated within the small data structure, and thus various types of
small-data-section relocations are valid for it. Then we do stuff like
"(void *)&foo - large_constant" which don't work with those sorts of
relocations.
I didn't explore the space of possible solutions, merely gave Rusty a
solution that I knew would work, and would never fail because the
compiler would never look through the asm.
I wouldn't be surprised if the compiler thought "(long)&foo -
large_constant" could be put back together into a small-data relocation,
simply because at the level at which that optimization is performed,
we've thrown away type data like long and void*; we only have modes.
Why are you wanting to change this at all? It works as it is.
r~
next prev parent reply other threads:[~2009-01-15 23:15 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <200901100040.n0A0eruc013680@imap1.linux-foundation.org>
[not found] ` <200901102211.45603.rusty@rustcorp.com.au>
2009-01-10 12:29 ` [patch 2/8] compiler-gcc.h: add more comments to RELOC_HIDE Ingo Molnar
2009-01-12 17:33 ` Christoph Lameter
[not found] ` <200901151227.27935.rusty@rustcorp.com.au>
2009-01-15 3:33 ` Linus Torvalds
2009-01-15 19:19 ` Christoph Lameter
2009-01-15 22:44 ` Andi Kleen
2009-01-15 20:29 ` Christoph Lameter
2009-01-15 23:15 ` Richard Henderson [this message]
2009-01-16 20:37 ` Christoph Lameter
2009-01-19 16:30 ` Richard Henderson
2009-01-21 13:50 ` Christoph Lameter
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=496FC375.90408@twiddle.net \
--to=rth@twiddle.net \
--cc=ak@linux.intel.com \
--cc=akpm@linux-foundation.org \
--cc=andi@firstfloor.org \
--cc=cl@linux-foundation.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=rusty@rustcorp.com.au \
--cc=sfr@canb.auug.org.au \
--cc=torvalds@linux-foundation.org \
--cc=travis@sgi.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox