This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
Re: libtool linking libgcj
- From: David Daney <ddaney at avtrex dot com>
- To: Bryce McKinlay <bryce at mckinlay dot net dot nz>
- Cc: Andrew Haley <aph at redhat dot com>, java at gcc dot gnu dot org
- Date: Mon, 29 Sep 2003 16:26:13 -0700
- Subject: Re: libtool linking libgcj
- References: <D6D0AD4A-F2D2-11D7-9328-003065F97F7C@mckinlay.net.nz>
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