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 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]