RFH/RFC: symbol index overflow in MIPS linker stubs...

David Daney ddaney@avtrex.com
Wed Jun 7 19:45:00 GMT 2006


Thiemo Seufer wrote:
> David Daney wrote:
> 
>>I am doing some testing of the gcj java compiler that is part of 
>>gcc-4.2, and have come across a problem.
>>
>>This is the ld version I am using:
>>$ mipsel-linux-ld --version
>>GNU ld version 2.16.91 20050817
>>
>>libgcj.so.7 contains more than 2^15 symbols in its symbol table.  If a 
>>linker stub requires an index for a symbol that has an index greater 
>>than 2^15, then the index gets sign extended into a negative number. 
>>The result is a SIGSEGV at runtime when ld.so tries to look up the 
>>symbol with a negative index.
> 
> 
> Thank you for debugging this long-standing problem.
> 
> 
>>Here is a dissassembly that shows the problem:
>>
>>
>> # objdump -d -z -j .MIPS.stubs /lib/libgcj.so.7
>>
>>/lib/libgcj.so.7:     file format elf32-tradlittlemips
>>
>>Disassembly of section .MIPS.stubs:
>>
>>01597f40 <.MIPS.stubs>:
>> 1597f40:       8f998010        lw      t9,-32752(gp)
>> 1597f44:       03e07821        move    t7,ra
>> 1597f48:       0320f809        jalr    t9
>> 1597f4c:       241897cd        li      t8,-26675
>> 1597f50:       8f998010        lw      t9,-32752(gp)
>> 1597f54:       03e07821        move    t7,ra
>> 1597f58:       0320f809        jalr    t9
>> 1597f5c:       241897b2        li      t8,-26702
>>
>>
>>Note that the symbol index loaded into t8 is negative.
>>
>>I think we could easily change the stubs so that they used ori (an 
>>unsigned immediate load), instead of li.  This would work for symbol 
>>tables of size up to 2^16.
>>
>>FWIW: I tested this theory by hand editing the stubs to use the unsigned 
>>immediate load and the library now runs correctly.
> 
> 
> That's STUB_LI16 in bfd/elfxx-mips.c:635, used at line 8020. The FIXME
> immediately above the latter line is also interesting.
> 
> 
>>A second option might be to use a two instruction sequence to load t8, 
>>but that would change the size of the stubs.  I don't know if that would 
>>be portable or possible.
>>
>>Comments please.
> 
> 
> I would favour a two instruction sequence, applications will continue to
> grow. There might be some compatibility traps, but at a superficial
> glance I haven't found an obvious blocker.
> 

Unless you want to fix it, I will work on a patch.

David Daney



More information about the Binutils mailing list