* LTO and asm specs...
@ 2010-03-13 12:42 David Miller
2010-03-16 19:28 ` Richard Henderson
0 siblings, 1 reply; 6+ messages in thread
From: David Miller @ 2010-03-13 12:42 UTC (permalink / raw)
To: gcc
There is one g++ LTO test case (g++.lto/20090303) that fails on sparc,
it compiles the intermediate objects with -fPIC but the final
compilation creates an executable.
The problem is that when LTO re-instantiates the options for the
individual builds, the proper ASM specs of the target are not
executed, so in this case "-K PIC" is not passed down to the assembler
in response to "-fPIC".
As a consequence, relocations against _GLOBAL_OFFSET_TABLE_
in code like this:
sethi %hi(_GLOBAL_OFFSET_TABLE_), %g1
use the R_SPARC_HI22 relocation instead of R_SPARC_PC22.
Thus the program crashes.
I couldn't figure out immediately how to fix this as the
way LTO does spec overriding and such looked non-trivial.
Thanks.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: LTO and asm specs...
2010-03-13 12:42 LTO and asm specs David Miller
@ 2010-03-16 19:28 ` Richard Henderson
2010-03-16 19:34 ` David Miller
0 siblings, 1 reply; 6+ messages in thread
From: Richard Henderson @ 2010-03-16 19:28 UTC (permalink / raw)
To: David Miller; +Cc: gcc
On 03/12/2010 09:33 PM, David Miller wrote:
> I couldn't figure out immediately how to fix this as the
> way LTO does spec overriding and such looked non-trivial.
It would not be a bad thing, IMO, if the sparc assembler
were extended to be able to emit any reloc directly, without
needing a specific command-line option. Then you'd only
encounter this problem with legacy assemblers.
r~
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: LTO and asm specs...
2010-03-16 19:28 ` Richard Henderson
@ 2010-03-16 19:34 ` David Miller
2010-03-16 19:57 ` Richard Henderson
2010-03-16 20:14 ` H.J. Lu
0 siblings, 2 replies; 6+ messages in thread
From: David Miller @ 2010-03-16 19:34 UTC (permalink / raw)
To: rth; +Cc: gcc
From: Richard Henderson <rth@redhat.com>
Date: Tue, 16 Mar 2010 11:31:44 -0700
> On 03/12/2010 09:33 PM, David Miller wrote:
>> I couldn't figure out immediately how to fix this as the
>> way LTO does spec overriding and such looked non-trivial.
>
> It would not be a bad thing, IMO, if the sparc assembler
> were extended to be able to emit any reloc directly, without
> needing a specific command-line option. Then you'd only
> encounter this problem with legacy assemblers.
It's not the assemblers fault.
We're using %hi() and expecting the assembler to emit a
PC relative relcation just because the symbol name happens
to be _GLOBAL_OFFSET_TABLE_ And it will do this, but only
when -PIC. Changing that is pretty dangerous.
But even if we got past that, we need to get the assembler options
right in order to enable instruction classes. For example we have to
get -Av9a there when using VIS instructions.
Other platforms are going to hit things like this too.
LTO really needs to evaluate the specs correctly.
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: LTO and asm specs...
2010-03-16 19:34 ` David Miller
@ 2010-03-16 19:57 ` Richard Henderson
2010-03-16 19:58 ` David Miller
2010-03-16 20:14 ` H.J. Lu
1 sibling, 1 reply; 6+ messages in thread
From: Richard Henderson @ 2010-03-16 19:57 UTC (permalink / raw)
To: David Miller; +Cc: gcc
On 03/16/2010 12:28 PM, David Miller wrote:
> It's not the assemblers fault.
>
> We're using %hi() and expecting the assembler to emit a
> PC relative relcation just because the symbol name happens
> to be _GLOBAL_OFFSET_TABLE_ And it will do this, but only
> when -PIC. Changing that is pretty dangerous.
It is the assembler's fault because it doesn't provide %pcrelhi() or
some such to allow the compiler (or asm programmer) to emit exactly
the relocation that's desired.
> But even if we got past that, we need to get the assembler options
> right in order to enable instruction classes. For example we have to
> get -Av9a there when using VIS instructions.
How about ".arch v9a" like other platforms emit?
Command-line options that control what the assembler emits for
the exact same bit of text are a Really Bad Idea, as we've seen
from other platforms time and time again.
r~
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: LTO and asm specs...
2010-03-16 19:57 ` Richard Henderson
@ 2010-03-16 19:58 ` David Miller
0 siblings, 0 replies; 6+ messages in thread
From: David Miller @ 2010-03-16 19:58 UTC (permalink / raw)
To: rth; +Cc: gcc
From: Richard Henderson <rth@redhat.com>
Date: Tue, 16 Mar 2010 12:53:47 -0700
> On 03/16/2010 12:28 PM, David Miller wrote:
>> It's not the assemblers fault.
>>
>> We're using %hi() and expecting the assembler to emit a
>> PC relative relcation just because the symbol name happens
>> to be _GLOBAL_OFFSET_TABLE_ And it will do this, but only
>> when -PIC. Changing that is pretty dangerous.
>
> It is the assembler's fault because it doesn't provide %pcrelhi() or
> some such to allow the compiler (or asm programmer) to emit exactly
> the relocation that's desired.
There is %pc22() and %pc10. I don't know if it's safe to
change gcc to use them in all cases though.
>> But even if we got past that, we need to get the assembler options
>> right in order to enable instruction classes. For example we have to
>> get -Av9a there when using VIS instructions.
>
> How about ".arch v9a" like other platforms emit?
>
> Command-line options that control what the assembler emits for
> the exact same bit of text are a Really Bad Idea, as we've seen
> from other platforms time and time again.
I think this distracts from the issue that LTO needs to
process specs properly.
Are you seriously against fixing that LTO bug?
^ permalink raw reply [flat|nested] 6+ messages in thread
* Re: LTO and asm specs...
2010-03-16 19:34 ` David Miller
2010-03-16 19:57 ` Richard Henderson
@ 2010-03-16 20:14 ` H.J. Lu
1 sibling, 0 replies; 6+ messages in thread
From: H.J. Lu @ 2010-03-16 20:14 UTC (permalink / raw)
To: David Miller; +Cc: rth, gcc
On Tue, Mar 16, 2010 at 12:28 PM, David Miller <davem@davemloft.net> wrote:
> From: Richard Henderson <rth@redhat.com>
> Date: Tue, 16 Mar 2010 11:31:44 -0700
>
>> On 03/12/2010 09:33 PM, David Miller wrote:
>>> I couldn't figure out immediately how to fix this as the
>>> way LTO does spec overriding and such looked non-trivial.
>>
>> It would not be a bad thing, IMO, if the sparc assembler
>> were extended to be able to emit any reloc directly, without
>> needing a specific command-line option. Then you'd only
>> encounter this problem with legacy assemblers.
>
> It's not the assemblers fault.
>
> We're using %hi() and expecting the assembler to emit a
> PC relative relcation just because the symbol name happens
> to be _GLOBAL_OFFSET_TABLE_ And it will do this, but only
> when -PIC. Changing that is pretty dangerous.
>
> But even if we got past that, we need to get the assembler options
> right in order to enable instruction classes. For example we have to
> get -Av9a there when using VIS instructions.
>
> Other platforms are going to hit things like this too.
>
> LTO really needs to evaluate the specs correctly.
>
Can you store assembler options in some LTO section?
--
H.J.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2010-03-16 20:00 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2010-03-13 12:42 LTO and asm specs David Miller
2010-03-16 19:28 ` Richard Henderson
2010-03-16 19:34 ` David Miller
2010-03-16 19:57 ` Richard Henderson
2010-03-16 19:58 ` David Miller
2010-03-16 20:14 ` H.J. Lu
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).