Re: Please reenable GCJ on mips
On Fri, Oct 07, 2005 at 05:39:26PM +0200, Thiemo Seufer wrote:
> We have for MIPS:
>
> - The plain GOT mode, where a GOT has a maximum size of 2^16 byte,
> with 16k symbols.
>
> - The XGOT mode, with unlimited (2^32 byte) size, which increases
> code size by 15-20%, and reduces perfomance accordingly.
>
> - MultiGOT, which creates several GOTs in a single binary for the
> final link, but uses only one GOT for imports/exports. The object
> files still have only plain GOT.
>
> MultiGOT is supposed to be the current best solution, and XGOT is
> supposed to be obsoleted by it. Normally plain GOT is used, and the
> linker switches to MultiGOT in the final link if the GOT grows too
> big.
Yes.
> - MultiGOT works fine, until the limit of 16k _dynamic_ symbols is
> hit. A executable/library with larger exported GOT will build
> without warning but will cause ld.so to segfault. This is the main
> bug, and hard to debug (a statically built gdb may help here).
> This hits currently (at least) the gcj shared library runtime,
> the ghc executable, and libgklayout.so in mozilla*. A workaround
> involving XGOT is possible in some cases, and was done for the
> mozillae (and some others, grepping for -xgot in build logs seems
> to be the most reliable way to find them all). Dynamically linked
> executables/shared libraries with any of the different internal GOT
> models are freely mixable.
If you'll give me an explicit testcase, I will volunteer to debug this
for you; I have lots of practice debugging ld.so. Is this really the
main bug at this point? I.E. multigot binaries not working rather than
not linking?
--
Daniel Jacobowitz
CodeSourcery, LLC
Reply to: