This is the mail archive of the mailing list for the binutils project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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
> 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 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/
> /lib/     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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]