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

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).

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: