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
_______________________________________________
http://lists.milkymist.org/listinfo.cgi/devel-milkymist.org
IRC: #milkymist@Freenode
