[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