linux-origin
[Top] [All Lists]

Re: mips64 boot

To: linux-origin@xxxxxxxxxxx
Subject: Re: mips64 boot
From: dagum@xxxxxxxxxxxxxxxxxxx (Leo Dagum)
Date: Sat, 26 Feb 2000 20:47:42 -0800
References: <20000226024649.A18436@xxxxxxxxxxxxxx> <Pine.LNX.4.10.10002260201290.1895-100000@xxxxxxxxxxxxxxxxxxxx>
Sender: owner-linux-origin@xxxxxxxxxxx
> From: Ralf Baechle <ralf@xxxxxxxxxxx>
> 
> On Sat, Feb 26, 2000 at 02:20:46AM -0800, Ulf Carlsson wrote:
> 
> > > The situation for userland is different and much more complex.  GNU libc 
> > > and
> > > other packages do heavily rely on GNU ld's features.  Add that GNU ld is
> > > evolving.  That makes using anything but GNU ld a no go for userspace.
> > 
> > I was talking to Ralf earlier and I mentioned that I thought SGI was going 
> > to
> > use the MIPS Pro compiler to compile the Linux that will run on the IA-64 
> > SN1
> > machines.  I really don't know what's happening with the MIPS Pro compiler
> > nowadays, I've only heard rumours from here and there.  If the MIPS Pro
> > compiler is going to be used to compile Linux I assume that the GNU specific
> > features required to compile the GNU libc, such as symbol versioning, will 
> > be
> > added, and we can use the features for MIPS as well as IA-64.  Does anyone
> > know whether the MIPS Pro compiler for IA-64 will be open sourced or not?

The back-end is going to be open sourced (code generation and optimization), 
the front end remains gcc.
See:

http://info.engr.sgi.com/opensrc/proposals/compiler.html

> 
> In that context it may make sense to consider compiler, assembler and
> linker as related but not directly dependent parts.
> 
> As said GNU ld and binutils are really insane pieces of code.  Expressing
> it with Alan Cox's words: ``and yes bfd hacking is like doing sendmail
> configs blind with a belgian keyboard''.  And yes, bfd is indeed the
> abreviation for Big Fucking Deal.  The alternative expansion Binary File
> Descriptor library was created later on ...
> 
> I would really, really hate if we'd use a different assembler and linker
> than all the others Linux architectures.  It would still leave us with
> with a broken libbfd which various tools are linked against.  The most
> important one of these is GDB and GDB functionality on IRIX already
> suffers a good bit from the brokenness of libbfd on MIPS.  I just say
> N32 and 64 ABIs.
> 
> As mentioned before people at Cygnus have considered replacing GNU ld
> years ago.  Most important to drop everything but ELF support for a
> ld replacement.  With that happening and a new ld going into binutils
> libbfd still wouldn't be eleminated.  But large parts of it's
> functionality could be eleminated, the complexity by reduced dramatically.
> Result: only winners, at least among the ELF users.  So after some
> brain storming I think we should try to convince the other architectures
> that GNU ld is really overdue to be replaced.  Probbly little convincing
> required.  What we get is hopefully some linker that is maintainable for
> us again.

That makes some sense as a long term strategy, but do you really want to 
continue doing battle with binutils until a new loader comes along from
Cygnus?  

I didn't think so.

- leo

> 
>   Ralf
> 
Leo Dagum    SGI  Mountain View, CA 94043 (650-933-2179)

<Prev in Thread] Current Thread [Next in Thread>