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

Re: Please reenable GCJ on mips

Daniel Jacobowitz wrote:
> It's a lot of work to fix and no one has done it.  That's not the same
> thing at all.

That's nice, but there's still a real problem unrelated to that.

An example of a relatively healthy bug which is "a lot of work to fix and no 
one has done it" is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=6257, the 
problem of distinguishing between #include <cstdio> and #include <stdio.h> in 
C++ programs and getting the collection of included symbols correct for both 
cases.  There's a fairly substantial amount of information on the problems 
and attempted solutions.

Another example is http://gcc.gnu.org/bugzilla/show_bug.cgi?id=5911 -- the 
screwball way Ada is built in GCC -- where the work to fix it is totally 
straightforward, but very large and very tedious.

What I keep hearing is that no one has reported the bug(s), and nobody except 
Thiemo Seufer has even described it/them adequately.  This is a bug or bugs 
which is not documented in the documentation or bug databases for glibc, 
binutils, gcc, Debian, or anywhere else.  It's apparently a substantial and 
reproducible bug which hits any library or executable with really large 
numbers of exported symbols.  The GCC documentation suggests a fix (xgot) 
which doesn't actually work.

That is bad.
* Either ld or gcc (or both) should note in its documentation that xgot is 
incompatible with multigot.  Alternatively, there should be a bug report 
against ld because of this.  I haven't determined which is considered correct 

* The failure of multigot to support >16K of exported symbols is a bug 
somewhere, but I'm still not clear whether it's an ABI limitation or or a bug 
in the dynamic linker.  If the latter, it needs to be reported.  If the 
former, it needs to be documented.

Now, I understand this sort of stuff not being dealt with for a while.  But 
the nature of the problem has supposedly been known for a year or more, and 
so a little documentation of "known limitations" is really the least I'd 

m68k is known to be in a situation where serious toolchain bugs are not 
reported upstream.  I thought previously that it was the only such 

Reply to: