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

Re: nature of GOT bugs (was Re: Please reenable GCJ on mips

Nathanael Nerode wrote:
> 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.)

No need for hypotheses.

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

That (it shouldn't segfault), and/or potentially also a bug in ld which
leads to failure for large MultiGOT binaries.

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

No. It is limited to dynamic symbols.


Reply to: