* or a bug in ld.so -- inability to handle correctly specified multiple
GOTs
for more than 16k global symbols
Thiemo wrote:
That (it shouldn't segfault), and/or potentially also a bug in ld which
leads to failure for large MultiGOT binaries.
Rocking. It looks like most people involved
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
On Fri, Oct 07, 2005 at 05:39:26PM +0200, Thiemo Seufer wrote:
We have for MIPS:
- The plain GOT mode, where a GOT has a maximum size of 2^16 byte,
with 16k symbols.
- The XGOT mode, with unlimited (2^32 byte) size, which increases
code size by 15-20%, and reduces perfomance
Daniel Jacobowitz wrote:
[snip]
- 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
On Sat, Oct 08, 2005 at 09:11:05PM +0200, Thiemo Seufer wrote:
Daniel Jacobowitz wrote:
[snip]
- 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.
On Sat, Oct 08, 2005 at 03:18:23PM -0400, Nathanael Nerode wrote:
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,
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
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
Hi Nathanael,
Nathanael Nerode wrote:
And for pkg-java-maintainers:
* Why was kaffe deliberately broken on mips and mipsel?
It was never _deliberately_ broken on mips and mipsel. On mipsel jikes
went broken and as there is no gcj available we have no option to compile
kaffe there at the
Hi,
* Nathanael Nerode ([EMAIL PROTECTED]) [051007 04:42]:
Matthias Klose wrote:
If
you think, that availability of compilers on some architectures
should be release criterium, please bring that up with the release
team first.
That's not at all what I think.
I think that if there
Andreas Barth wrote:
Actually, there is one criterion missing: Does this bug really hurt us
bad (enough)? And my current answer to this is no, but of course, you
might want to persuade me. :)
...
So, I think we can say that this bug is even forwarded to upstream, as
mips Inc is aware of it
Nathanael Nerode wrote:
Matthias Klose wrote:
If
you think, that availability of compilers on some architectures
should be release criterium, please bring that up with the release
team first.
That's not at all what I think.
I think that if there are known binutils bugs for your
Andreas Barth wrote:
Hi,
* Nathanael Nerode ([EMAIL PROTECTED]) [051007 04:42]:
Matthias Klose wrote:
If
you think, that availability of compilers on some architectures
should be release criterium, please bring that up with the release
team first.
That's not at all what I
Nathanael Nerode wrote:
Andreas Barth wrote:
Actually, there is one criterion missing: Does this bug really hurt us
bad (enough)? And my current answer to this is no, but of course, you
might want to persuade me. :)
...
So, I think we can say that this bug is even forwarded to upstream, as
On Fri, Oct 07, 2005 at 05:16:28AM -0400, Nathanael Nerode wrote:
I begin to get the picture.
Apparently the MIPS ABI is just plain broken. It contains some sort of
impassable hard limit on relocation table size, breaking random packages at
random times with no possible fix. Nobody can
Apparently the MIPS ABI is just plain broken. It contains some sort of
impassable hard limit on relocation table size, breaking random packages at
random times with no possible fix. Nobody can fix this without changing
the ABI.
Thiemo Seufer wrote:
That's wrong.
OK. Can somebody
Nathanael Nerode wrote:
Apparently the MIPS ABI is just plain broken. It contains some sort of
impassable hard limit on relocation table size, breaking random packages
at
random times with no possible fix. Nobody can fix this without changing
the ABI.
Thiemo Seufer wrote:
I notice that GCJ ( company) are not built on mips or mipsel.
What I can't figure out is why.
GCJ is supported for mips*-*-linux* (except for mips64*-*-linux*, which
is not supported) upstream in the 4.0 series, and I couldn't find any
reported bugs on problems specific to it.
GCJ was orginially
Nathanael Nerode wrote:
I notice that GCJ ( company) are not built on mips or mipsel.
What I can't figure out is why.
GCJ is supported for mips*-*-linux* (except for mips64*-*-linux*, which
is not supported) upstream in the 4.0 series, and I couldn't find any
reported bugs on problems
[EMAIL PROTECTED]:
The toolchain (more specifically: ld) can't handle the gcj runtime
build yet. Btw, ghc triggers the same problem, there were several
reports filed for the various instances of this bug.
Ah, I see. So it's binutils which can't handle it. No wonder I couldn't find
any bug
Nathanael Nerode writes:
This is no way to get a bug fixed. If this is seriously the level of
attention to mips and mipsel, Debian support for them should be dropped.
sorry, this attitude has nothing to do with release management, it's
just ranting. The problem is addressed, known to the
Nathanael Nerode writes:
This is no way to get a bug fixed. If this is seriously the level of
attention to mips and mipsel, Debian support for them should be dropped.
Matthias Klose wrote:
sorry, this attitude has nothing to do with release management, it's
just ranting.
The problem is
Nathanael Nerode writes:
Nathanael Nerode writes:
This is no way to get a bug fixed. If this is seriously the level of
attention to mips and mipsel, Debian support for them should be dropped.
Matthias Klose wrote:
sorry, this attitude has nothing to do with release management, it's
Matthias Klose wrote:
If
you think, that availability of compilers on some architectures
should be release criterium, please bring that up with the release
team first.
That's not at all what I think.
I think that if there are known binutils bugs for your architecture, which
supposedly
24 matches
Mail list logo
