Re: Please reenable GCJ on mips
Thiemo Seufer wrote:
>You are mistaken (since I'm also upstream)
Upstream for binutils? Yes, you're one of two MIPS maintainers, second after
Eric Christopher, and there are also nine global maintainers.
And apparently nobody has documented this bug in the documentation for ld, or
bfd, or binutils, or as far as I can tell the source files for any of them,
or the bug database for binutils.
I finally found your message on debian-release:
http://lists.debian.org/debian-release/2004/09/msg00231.html
>Now to the xgot/multigot stuff: The normal GOT size on mips/mipsel
> is limited to 16k entries for both local and global symbols.
> Everything exceeding this limit had to use xgot, which is
> practically unlimited but less efficient.
How much less efficient? Factor of two? Worse? Is there a good reason this
was avoided on normal systems (as opposed to specialized high-performance use
cases)? Three instructions instead of one to fetch a global symbol -- it
really doesn't sound like a big deal of the "worth breaking large programs to
avoid" variety, since fetching global symbols shouldn't be the majority of
the code of a program.
> Beginning with binutils 2.14, multigot was introduced, which uses
> several GOTs in the binary, but is limited to a single GOT for
> globals, which means 16k globals at most.
OK, that's a broken ABI all right. :-)
> Mozilla's libgklayout.so
> has currently 19k globals, so it tries to use xgot.
Is this the same problem with GCJ: more than 16K of globals?
> Multigot is (supposed to be) transparent to the user, but in its
> current implementation it appears to conflict with xgot. The xgot
> specific relocations are distorted, and binutils is silent about
> this breakage.
I take it this is still the case. This is a binutils bug (without a bugzilla
entry).
> Xgot fails in current binutils when multigot kicks in, i.e. when
> the GOT gets larger than 64kB, which is the whole point of xgot.
I take it this is still the case. This, I suppose, is another binutils bug
(without a bugzilla entry).
> Commenting out the multigot handling in bfd/elfxx-mips.c allows
> binutils to handle this correctly, but that's of course no good
> option for non-xgot builds.
>
> The binutils xgot/multigot bug is not yet reported in the BTS.
Still true. Nor is it in the upstream Bugzilla. If it had been in *either
place* this would have been a much simpler search.
> Gcc's and glibc's crt* files are not built with xgot support. The
> glibc crt* cause no immediate problems, but gcc crt* cause segfaults
> in contructors.
...does this mean "segfaults when built with xgot support"? That qualifies as
a reportable (but unreported) GCC bug which can probably be fixed. Or does
this mean "segfaults when built without xgot support and linked with programs
built with xgot"?
> The Linker is silent about this breakage.
>
> Enabling xgot support unconditionally would increase the size of
> each binary by a few byte. That would be IMHO tolerable, but
> multigot links may break on it (I haven't tested this). So ATM,
> xgot and multigot seem to be mutually exclusive.
I take it this is still the case.
> This also means
> that the suggested patch in #270620 is probably a bad idea.
>
> With multigot disabled in binutils, the gcc patch for crt* with
> xgot support and some unrelated fixes to mozilla's xpcom layer
> I was able to create working mips packages of mozilla-firefox
> (#270621) and mozilla-thunderbird (#267017). The monolithic mozilla
> (#266850) is likely to work that way as well.
>
> I have currently no good idea how to fix this mess.
The correct solution was obvious before binutils 2.14: switch to xgot
unconditionally, and build everything that way. (Unless there's another
unreported bug regarding that.) Unfortunately the introduction of multigot
made that more difficult; probably now there are bunches of multigot-compiled
programs in Debian which would break until rebuilt if the transition was
made. Blech.
Nevertheless, it's probably still the right thing to do; multigot appears to
have multiple possible failure modes, so unless it's xgot-compatible, it's a
bad idea. :-P Is it possible to make multigot handle cases as big as xgot,
or is it theoretically impossible?
Reply to: