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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
