Thanks *very much* for your help explaining this mess. Thiemo Seufer wrote: > - A too large object file can overflow plain GOT. This is not only > MIPS-specific, it affects several architecture's toolchains, Right, it would affect any architecture which does silly things like having a 16-bit limit for GOT indices.
> and > was exposed pre-sarge (IIRC most virulently on sparc) by a > broken/deficient libtool which relinked things into a single huge > object file. > libtool was fixed, and the remaining cases (like a huge blob of > generated C code for python bindings) learned to split the C > source to some smaller pieces, which also helped link speed. > For MIPS, and if the need arises, this could be worked around by > using XGOT, but see below. The real fix would be a MultiGOT > extension to the object format, which is possible in a downward > compatible way but not implemented yet. From your description, I take it this does not apply to shared libraries or executables, only to individual .o files? So there is a MultiGOT extension to the specification for shared libraries and executables, but not for intermediate object files? :-O (Or... see below for my other hypothesis.) > > - 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). Okay. Is this considered * a bug in the MultiGOT specification -- no specification for how to handle more than 16k global symbols properly on MIPS * or a bug in ld.so -- inability to handle correctly specified multiple GOTs for more than 16k global symbols From your description I'm guessing this one is the case. In which case it's a bug in *glibc* which isn't in glibc Bugzilla. Which is understandable considering how new glibc Bugzilla is. * Or is this actually an artifact of the first problem? Perhaps MultiGOT uses trickery to allow symbols within a single executable or shared library to work -- because they aren't externally visible, they can use whatever convention ld sees fit -- but it can't be used at an interface boundary, because there's not actually a real specification for it. In this case an actual MultiGOT extension to the executable/library format would solve the problem. But wait -- that doesn't make sense. *This* bug does not appear to hit anyone but MIPS. That means that everyone else knows how to advertise more than 16k of exported symbols in a library. (Or that there's something funny about the MIPS ABI which causes it to require the export of a lot more symbols than anyone else requires.) > - XGOT and MultiGOT are mutually exclusive, because the MultiGOT > handling ignores XGOT relocations. This is arguably not a bug, > since MultiGOT is supposed to supersede XGOT. It is arguably a bug, I guess, that MultiGOT does not in actual fact supersede XGOT, failing in significant cases where XGOT works. :-P