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?
Yes.
> :-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
No.
> * 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.
Thiemo
Reply to: