libtool linking libgcj

David Daney ddaney@avtrex.com
Mon Sep 29 23:33:00 GMT 2003


Bryce McKinlay wrote:
> On Tuesday, Sep 30, 2003, at 10:50 Pacific/Auckland, David Daney wrote:
>>> On some platforms (MIPS o32) it has been said that this type of 
>> incremental linking (and the current way that libtool does it also) 
>> is the cause of GOT overflow problems, for which the only known work 
>> around is to enable a large GOT which results in slower code.
>>> Under the new BC-ABI libgcj should have a much smaller GOT, so I don't 
> think this will be an issue. Besides, why should the way you link 
> affect the final GOT size? If it does, it sounds like a linker bug to me.

Perhaps, but consider this:
The GOT pointer is initialized in the method prolog and each method has 
exactly one GOT.
The linker does not know where each method begins and ends, so it must 
assume that the entire object file is one method and use only one GOT 
for that object file.
The small GOT can only hold 16k entries.
If you link in stages (like libtool does) you can build up to object 
files that cause GOT overflows even if linking the individual object 
files would not cause the overflow. This is because multiple GOTs can 
be generated for a shared object, but the input object files must be 
assumed to have only one.
David Daney


More information about the Java mailing list

AltStyle によって変換されたページ (->オリジナル) /