[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.


>   - 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: