On Tue, Mar 16, 2010 at 12:28 PM, David Miller wrote:
> From: Richard Henderson
> 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.
>>
>>
From: Richard Henderson
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_
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 d
From: Richard Henderson
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
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 specifi
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
ex
