[Milkymist-devel] RFA: LM32: Fix building libgcc
Sébastien Bourdeauducq
sebastien.bourdeauducq at lekernel.net
Tue Sep 4 15:01:14 PDT 2012
Hi,
sorry for the delayed answer, I'm traveling and have limited time and
access to internet.
The first part of your patch (...SYMBOL_REF_FLAGS (x) |=
SYMBOL_FLAG_SMALL;) actually resolves the infinite recursion problem I
encountered. Now I get the same ICE in var-tracking.c as you.
I'm however worried that this first part might break the generated code
(I'm not 100% sure, but it seems related enough). In one example, which
loads the address of a string into r1, instead of having the correct
instruction sequence:
c: 78 01 00 00 mvhi r1,0x0
14: 38 21 00 00 ori r1,r1,0x0
with the two relocations:
0000000c 00000504 R_LM32_HI16 00000000 .rodata.str1.4 + 0
00000014 00000505 R_LM32_LO16 00000000 .rodata.str1.4 + 0
the new GCC generates:
c: 2b 41 00 00 lw r1,0
with one relocation:
0000000c 00000606 R_LM32_GPREL16 00000000 .rodata.cst4 + 0
You can reproduce the problem with a simple source code:
void foo(void)
{
bar("blah");
}
This also causes the linker to fail with a cryptic "warning: internal
error: dangerous error" message.
Sébastien
On 08/28/2012 12:45 PM, nick clifton wrote:
> Hi Sébastien,
>
>> is that with SVN head?
>
> Yes...
>
>> The problem we're having is actually that
>> infinite recursion segfault, and it happens very soon (libgcc configure
>> cannot even complete).
>
> Not to me...
>
>> are you building on 32-bit x86?
>
> Yes...
>
>
> The only local patch that I have applied is my lm32 one. I have
> attached another copy of it here. Perhaps I made a fix and forgot to
> mention it ? (That would not surprise me, I am juggling several
> different local builds at the moment).
>
> Cheers
> Nick
>
>
>
More information about the Devel
mailing list