> > * 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 inv
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 do
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/b
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
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 seg
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 buil
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 perfom
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-bi
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 binut
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
>> 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 someb
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 c
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 up
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
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
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 and
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
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 mome
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 pr
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, i
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 a
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 ri
[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 re
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
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
25 matches
Mail list logo
