nature of GOT bugs (was Re: Please reenable GCJ on mips
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
Reply to: