Subject: stable binutils, gcc, glibc ...

From: Jun Sun <[email-masked]>
Date: Fri, 13 Oct 2000 22:13:23 -0700

Sorry to bring this topic again, but I cannot seem to sort out all the
pieces of info together to get a consistent picture.  Below is what I
gathered through the recent emails on the lists.  Please take a look and
correct any mistakes.  Particularly I like to know which version is
considered STABLE today.  Perhaps there is also issue what version works
with what.

Also, let me know if I miss something.

In the end I like to put it on a web page and track the future toolchain
developments - for lazy hackers. :-)

Jun 

1. binutils
-----------

a) latest binutil cvs tree (v2.10) + debian patch

http://sourceware.cygnus.com/binutils/
ftp://ftp.rfc822.org/pub/local/debian-mips/patches/rel32-binutils.diff

b) Andreas Jaeger recommanded Ulf's patch against the CVS tree.  He
recommanded 

ftp://oss.sgi.com/pub/linux/mips/src/binutils/binutils-000420.diff.gz.  

But I only found the following file.

ftp://oss.sgi.com/pub/linux/mips/binutils/binutils-000424.diff.gz

c) What about those patches at the same ftp sites (v2.8.x)?

ftp://oss.sgi.com/pub/linux/mips/binutils/

2. gcc
-------

a) the cvs tree on oss.sgi.com (v2.7.2?) Any patch needed for TODAY's
tree?  Ralf seems to suggest his patch posted on 09/08 is still needed
(constructor, Keith gcse, etc).
 
b) Ralf's patch against egcs 1.1.2

ftp://oss.sgi.com/pub/linux/mips/src/egcs/egcs-1.1.2.diff.gz

c) Ralf's patch against egcs 1.0.3a.  (Where is the base tar ball?)

ftp://oss.sgi.com/pub/linux/mips/egcs/egcs-1.0.3a-2.diff.gz

d) Andreas said the current development version 2.96 worked - with the
later binutils and gcc.

3.glibc
-------

a) the cvs tree on oss.sgi.com (v2.0.6).  Any patch needed?

Florian pointed out the following patch.  I am not 100% sure if it is
aginst the current sgi CVS tree.  Any confirmation?

ftp://ftp.rfc822.org/pub/local/debian-mips/patches/rel32-glibc.diff

b) Andreas is trying to get glibc 2.2 working.  Definitely bleeding edge
stuff.

http://www.suse.de/%7Eaj/glibc-mips.html

c) Maciej reported he got binutils v2.10 working for glibc 2.2.  No
details or any distribution.

d) glibc v2.0.7 from linux-vr project by Jay

ftp://ftp.place.org/pub/nop/linuxce/
ftp://ftp.place.org/pub/nop/linuxce/rpms/glibc-2.0.7-20.src.rpm

---

From: Ralf Baechle <[email-masked]>
Date: Sat, 14 Oct 2000 05:55:50 +0200

> developments - for lazy hackers. :-)

The binutils paragraph is old new.  All of the required patches are now
in binutils except one which I sent to Ulf yesterday.

> ftp://oss.sgi.com/pub/linux/mips/binutils/

Still recommended because we can't yet be sure that binutils-cvs are
kosher yet.  For example it's suspect that I can't build Emacs.  Might
be something else but in case of doubt binutils are the suspect ...

> ftp://oss.sgi.com/pub/linux/mips/src/egcs/egcs-1.1.2.diff.gz

Only intended for mips64 kernels..  Almost guaranteed to be unusable for
anything else.

> c) Ralf's patch against egcs 1.0.3a.  (Where is the base tar ball?)

On your favorite GNU site.

> d) Andreas said the current development version 2.96 worked - with the

Plus above mentioned constructor patch.

Seems to work reasonably well.

> a) the cvs tree on oss.sgi.com (v2.0.6).  Any patch needed?

No.  However I'm not always doing the best job at keeping it uptodate.

> ftp://ftp.rfc822.org/pub/local/debian-mips/patches/rel32-glibc.diff

Against the glibc cvs tree at Cygnus.

> ftp://ftp.place.org/pub/nop/linuxce/rpms/glibc-2.0.7-20.src.rpm

2.0.7 has resulted in so many bug reports that I consider to plain dump any
related reports in the future.

  Ralf

---

From: Florian Lohoff <[email-masked]>
Date: Sat, 14 Oct 2000 12:55:32 +0200

> 1. binutils

Its not a debian patch - I just put it up when i got it out of Ralfs
Nose :)

> b) Andreas Jaeger recommanded Ulf's patch against the CVS tree.  He

Just use cvs 

> (constructor, Keith gcse, etc).

I am using current cvs - Which seems to do quiet well ...

> a) the cvs tree on oss.sgi.com (v2.0.6).  Any patch needed?

*urgs* 2.0.6 - I am currently building everything against 2.0.6 but
i rather now then later stop using it - But currently i am not using 2.2
because with the newest patch set by Ralf (glibc + binutils) i get
a bus error while using rpcgen with the freshly build 2.2 glibc in
the build process ...

> ftp://ftp.rfc822.org/pub/local/debian-mips/patches/rel32-glibc.diff

This is the corresponding patch to the binutils things - Doesnt solve
my problem though.

Flo
-- 
Florian Lohoff		[email-masked]		      	+49-5201-669912
      "Write only memory - Oops. Time for my medication again ..."

---

From: Florian Lohoff <[email-masked]>
Date: Sat, 14 Oct 2000 12:57:10 +0200

> be something else but in case of doubt binutils are the suspect ...

If its only emacs - I am happy :)

> Seems to work reasonably well.

For everything non glibc 2.2

> related reports in the future.

Ack

Flo

---

From: Ralf Baechle <[email-masked]>
Date: Sat, 14 Oct 2000 06:21:00 +0200

> in binutils except one which I sent to Ulf yesterday.

So Ulf commited the patch into the binutils cvs.  Therefore no more
pending patches for binutils-current.

  Ralf

---

From: Ralf Baechle <[email-masked]>
Date: Sat, 14 Oct 2000 14:41:12 +0200

> This is the corresponding patch to the binutils things - Doesnt solve

I got a newer libc 2.2 patch for you to try .  I'll make a new patch and
send it to you.

(All the GOT1_OK stupidity has to be removed from the patch you have.)

  Ralf

---

From: Ralf Baechle <[email-masked]>
Date: Sat, 14 Oct 2000 16:25:46 +0200

On Sat, Oct 14, 2000 at 07:33:35AM -0400, Christopher C. Chimelis wrote:

> Ugh.  Well, once you all figure out if binutils is to blame or if it's
> gcc, drop me a note and I'll make sure to spit out a binutils package that
> includes the good patch...

It's not obvious what's causing his problem.

Florian: Can you run elf/ld.so from your glibc 2.2 tree without any further
options or does it die?

  Ralf

---

From: "Jay Carlson" <[email-masked]>
Date: Sat, 14 Oct 2000 10:51:37 -0400

> related reports in the future.

Hey, don't blame me for the 2.0.6->2.0.7 version bump.  I just grabbed the
biggest version number on oss.sgi.com at the time and made my *trivial*
patches to add softfloat to the build.

Let me say that again: 2.0.7 is NOT MY FAULT.

:-)

Seriously, I think the best thing we can do in this situation is start
assigning our own linux-mips version numbers to combinations of upstream
sources and our patches.  So, we'd have something like:

  glibc 2.0.6 + 05lm patches (whatever) == glibc2.0.6 delta 1.0
  glibc 2.0.6 + 06lm patches (whatever) == glibc2.0.6 delta 1.1

  egcs 1.0.3a + ralf's current patches == egcs 1.0.3a delta 1.0
  egcs 1.0.3a + ralf's patches tomorrow == egcs 1.0.3a delta 2.0

  binutils 2.8.1 + standard patches == binutils 2.8.1 delta 1.0
  binutils 2.10.x on 20001014 == binutils 2.10.x delta 1.0
  binutils 2.10.x on 20001015 == binutils 2.10.x delta 2.1

We need to give *names* to the versions of the software we're testing
against.  I haven't bothered trying a world rebuild against gcc 2.96.x
because telling people it worked wouldn't mean anything.  Other people would
not know that they could reproduce my success by getting the same bits as
me.

What I really want to hear is: "I rebuilt gcc, binutils, the kernel,
modutils, and GNU fileutils using gcc 2.96 delta 7.3, binutils 2.10.x delta
5.2, and glibc 2.1.95 delta 1.0", and then know EXACTLY how to reproduce
that at home.  Just saying "current CVS with patches" doesn't help with
reproducibility.

Jay

---

From: Ralf Baechle <[email-masked]>
Date: Sat, 14 Oct 2000 17:09:28 +0200

> Let me say that again: 2.0.7 is NOT MY FAULT.

I didn't blame you - I didn't even know how came up with 2.0.7-mips.  When I
receive bug reports against the various 2.0.7 incarnations I just usually
find that they're that particular 2.0.7 version has bugs which were fixed
eternities ago.

2.0.7 as used by the distributors is probably a reasonably sane libc.

Do your softfp patches somehow cause problems with hardware fp machines?
If not we could throw all things together.

> that at home.  Just saying "current CVS with patches" doesn't help with

Actually I'm trying to kill this entire naming problem by getting all
patches back to the respective maintainers.  Result:  no pending patches
for cvs binutils, only tiny ones for glibc-current and egcs-current.

Naming the patches is a nice idea but frequently I find my own patches
again on some server with creativly changed names.  There is just nobody
who controls the namespace for those patches.

  Ralf

---

From: "Jay Carlson" <[email-masked]>
Date: Sat, 14 Oct 2000 12:11:38 -0400

> find that they're that particular 2.0.7 version has bugs which were fixed

Yeah.  You weren't blaming me, and I don't think Jun was blaming me, but my
name was attached to 2.0.7, and I wanted to escape....

> 2.0.7 as used by the distributors is probably a reasonably sane libc.

See, another naming issue...

> If not we could throw all things together.

No, no problems at all.  They're just conditional on __HAVE_FPU__.  Consider
ftp://ftp.place.org/pub/nop/linuxce/glibc-2.0.7-mips-softfloat.patch
submitted for the 2.0.6 branch.

I'm not really the head toolchain builder for linux-vr these days---Mike
Klar has a set of unified patches he's been working on.

> for cvs binutils, only tiny ones for glibc-current and egcs-current.

Yes.  This is very good.  This reduces the problem by one dimension---the
unique specification of a source version can be reduced to a date
(preferably the exact date you give to cvs checkout).  Given success
reports, other people can come along behind you and build tarballs and RPMs
given just that information.

Speaking of egcs-current---I hadn't looked at it in some time.  It appears
not to multilib for softfloat.

Could somebody who already has signatures on file with the FSF add multilib
softfloat for mips-linux targets?  I mean, we (linux-vr) *think* we're going
to be switching over to the FP emulator soon, but it hasn't happened yet.
Adding multilib is pretty harmless---I can't think of how it could screw up
the build for hardfp machines.

The biggest reason I can think of *not* to make such a change is because
there are already plans in the works to create a mipselnofp-linux target to
more closely describe the situation.  But I don't see any momentum behind
it, and I'd rather have either multilib or mipselnofp than the default case
of "linux-vr must ship patches and maintain separate .debs and .rpms that
contain a proper superset of mainline functionality".

> who controls the namespace for those patches.

True :-(  We do have the big hammer of linuxmips.org/linux-mips.org as a way
of handing out namespace if people actually want to cooperate on naming.

Jay

---

From: "Jay Carlson" <[email-masked]>
Date: Sat, 14 Oct 2000 12:11:39 -0400

[don't you hate it when you remember something you wanted to ask right after
you hit send?]

> for cvs binutils, only tiny ones for glibc-current and egcs-current.

What's going to happen to glibc 2.0.6?  I suspect the embedded people are
going to be stuck using it until we figure out how to trim down the binary
size of 2.2.

Jay

---

From: Ralf Baechle <[email-masked]>
Date: Sat, 14 Oct 2000 18:12:57 +0200

> going to be stuck using it until we figure out how to trim down the binary

Which why I guess we still have to maintain it for a while or even come
up with some alternative small libc.

  Ralf

---

From: "Bradley D. LaRonde" <[email-masked]>
Date: Sat, 14 Oct 2000 12:22:05 -0400

----- Original Message -----
From: "Ralf Baechle" <[email-masked]>
To: "Jay Carlson" <[email-masked]>
Cc: "Jay Carlson" <[email-masked]>; <[email-masked]>;
<[email-masked]>
Sent: Saturday, October 14, 2000 12:12 PM
Subject: Re: stable binutils, gcc, glibc ...

> up with some alternative small libc.

I am fine with using 2.0.6 for a long time, at least until some markedly
superior option is available.

Regards,
Brad

---

From: "Bradley D. LaRonde" <[email-masked]>
Date: Sat, 14 Oct 2000 12:29:33 -0400

----- Original Message -----
From: "Jay Carlson" <[email-masked]>
To: "Ralf Baechle" <[email-masked]>; "Jay Carlson" <[email-masked]>
Cc: <[email-masked]>; <[email-masked]>; "Mike Klar"
<[email-masked]>
Sent: Saturday, October 14, 2000 12:11 PM
Subject: RE: stable binutils, gcc, glibc ...

> > RALF: Do your softfp patches somehow cause problems with hardware fp
machines?
> > RALF: If not we could throw all things together.

> Klar has a set of unified patches he's been working on.

I would prefer to use mipsel tools and libraries from SGI and have the
linux-vr-specific stuff go away (with linux-vr just mirroring the SGI
stuff).

> contain a proper superset of mainline functionality".

I think that optimal for me would be if the tools from SGI worked for both
hard-float and soft-float, and we didn't have any linux-vr-specific tools.

Regards,
Brad

---

From: Florian Lohoff <[email-masked]>
Date: Sat, 14 Oct 2000 19:54:16 +0200

> Florian: Can you run elf/ld.so from your glibc 2.2 tree without any further

No it doesnt - Works as expected ... When running like

elf/ld.so --library-path . sunrpc/rpcgen

i get a "Bus Error"

Ill send you the LD_DEBUG=all ouput seperatly - It crashes after transfer
to the program ...

Flo

---

From: Keith Owens <[email-masked]>
Date: Sun, 15 Oct 2000 10:47:37 +1100

On Sat, 14 Oct 2000 18:12:57 +0200, 
>up with some alternative small libc.

Is there any reason that newlib is not being used for embedded systems?
That is what it was developed for.  There is some MIPS support in
newlib, I have no idea if it is complete but it would be better than
starting from scratch.  http://sources.redhat.com/newlib/

---

From: Ralf Baechle <[email-masked]>
Date: Mon, 16 Oct 2000 02:35:23 +0200

> hard-float and soft-float, and we didn't have any linux-vr-specific tools.

This is indeed the problem which I see with the softfp patch for libc.
Andreas Jaeger did work on the softfp stuff in glibc 2.2.  I don't know it's
exact status but if for size reasons you want to stick with glibc 2.0 a
backport might be of interest?

Have the other tools - in particular binutils and gcc actually been modified
except maybe changing defaults?

  Ralf

---

From: Ralf Baechle <[email-masked]>
Date: Mon, 16 Oct 2000 03:07:32 +0200

> starting from scratch.  http://sources.redhat.com/newlib/

Newlib, the libraries from eCOS and also libstand from NetBSD are three
candidates I know of.  I'm also interested in those small libraries as
the base for a standalone library that runs directly on the ARC firmware
or other firmware.

  Ralf

---

From: "Mike Klar" <[email-masked]>
Date: Sun, 15 Oct 2000 18:33:42 -0700

> except maybe changing defaults?

binutils we use unmodified from the cross- SRPM on ftp://oss.sgi.com.
egcs-1.0.3a did require a small patch, which Jay has at:
ftp://ftp.place.org/pub/nop/linuxce/egcs-1.0.3a-mips-softfloat.patch
I've reworked it slightly to patch cleanly against the latest Linux-MIPS
egcs-1.0.3a release, but the server that's on is a bit whacked at the moment
(the patch conflict was pretty trivial, though...).

We actually did not change the compiler default from hard-float, to compile
soft-float, the flag -msoft-float still has to be used.  Jay's patch just
makes -msoft-float work (with glibc), at least that's my understanding.

Mike Klar

---

From: Alan Cox <[email-masked]>
Date: Mon, 16 Oct 2000 08:00:26 +0100 (BST)

> Newlib, the libraries from eCOS and also libstand from NetBSD are three

The eCos library is an updated newlib.

Alan

---

From: "Jay Carlson" <[email-masked]>
Date: Mon, 16 Oct 2000 07:26:19 -0400

OK, might as well get this into the list archives......

> binutils we use unmodified from the cross- SRPM on ftp://oss.sgi.com.

Right.  Exact version of 2.8.1 was: cross-binutils-2.8.1-1.src.rpm

> (the patch conflict was pretty trivial, though...).

The patch does three things:

1) turns on multilib support for -msoft-float.  (This makes gcc install two
versions of libgcc.a etc: one in the lib/libgcc.a, one in
lib/softfloat/libgcc.a.)

2) asks the build process to include the actual soft float implementation
(fp-bit.c) in libgcc.a.  Note that this is probably not the optimal place
for it in the long run, because these functions should be shared.  I'm
pretty sure glibc 2.2 has them there, which isn't so bad a spot.

3) chooses the soft float API (function names, arg order).  Because every
other MIPS configuration included with gcc ignores the native GNU naming
convention in favor of the GOFAST API, I chose GOFAST.  I figured that the
sins of GOFAST's namespace pollution could be overlooked because Cygnus
would be more likely to fix mips softfloat problems that affected paying
embedded customers.   glibc's choice of native GNU naming convention makes
me regret this.

I think there will have to be a flag day eventually  because of 2 and/or 3.
Luckily, we can rebuild all the binaries we have without TOO much pain.  The
issue can be put off until we're ready to start using glibc 2.2, which may
be a while.

Does anyone know if gcc 2.97 can build glibc 2.0.x?

All of this is making me reconsider my request to install softfloat multilib
into gcc 2.97.  I don't understand how it will interact with glibc 2.2 yet.

> We actually did not change the compiler default from hard-float,

That's right.  For linux-vr, CC="mipsel-linux-gcc -msoft-float".

For the record, the glibc patch does two things:

1) longjmp/setjmp will only save FPU registers if __HAVE_FPU__ is defined.
In unmodified egcs 1.0.3a, "%{!msoft-float: -D__HAVE_FPU__ }".

2) conditionalizes _FPU_GETCW and _FPU_SETCW in fpu_control.h.  If I recall
correctly, _FPU_SETCW() is called early in program startup, even for
programs that will never touch the FPU.  This of course causes instant death
unless the kernel can emulate "ctc1 foo,$31"....

Let me know if this is boring you decstation folks.  By the way, anybody in
the Boston area want a free 5000/120?

Jay

---

From: Ralf Baechle <[email-masked]>
Date: Mon, 16 Oct 2000 13:30:10 +0200

> Does anyone know if gcc 2.97 can build glibc 2.0.x?

I'm using a glibc snapshot of about two weeks ago which seems to work fine
for glibc.  I however suspect it's making Emacs die and Emacs addicts
keep insisting that this isn't within spec ;-)

  Ralf

---

From: "Maciej W. Rozycki" <[email-masked]>
Date: Mon, 16 Oct 2000 17:41:45 +0200 (MET DST)

> ftp://oss.sgi.com/pub/linux/mips/binutils/binutils-000424.diff.gz

 I've forward-ported the patch to the final 2.10 release.  It's available
at ftp://ftp.ds2.pg.gda.pl/pub/macro/ and http://www.ds2.pg.gda.pl/~macro/
(the latter is slightly outdated though -- I need to update it from RPM
packages).

> details or any distribution.

 The package is available from ftp://ftp.ds2.pg.gda.pl/pub/macro/.  Newer
versions get uploaded as they are ready. 

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: [email-masked], PGP key available        +

---

From: Ralf Baechle <[email-masked]>
Date: Mon, 16 Oct 2000 14:00:05 +0200

> Does anyone know if gcc 2.97 can build glibc 2.0.x?

As I already wrote in my other email this seems to work.  However there is
a little minefiled hidden there which I should warn you about.  Sometimes
gcc emits references to __register_frame_info which is a libgcc defined
symbol.  This function happened to be defined coincidntally in libtermcap
and a few others such that these references so far usually were satisfied.
Now built with gcc 2.97 libtermcap no longer defines this symbol and so a
few programs like for example mutt2 or bash2 will die therefore.

If you then go and rebuild mutt / bash2 themselfes the static linker will
pull this function from libgcc.a and things will work again.  By then
everything will be like it was intended to be but still this means some
compatibility problem with older shared binaries..

> unless the kernel can emulate "ctc1 foo,$31"....

I would prefer to see that this patch using some mechanism which detects
the precense / absence of hardware fp at runtime and behaves accordingly.

You can implement this by protecting the ctc instruction in _FPU_SETCW with
a signal handler.  This already happens during the early libc startup, so
we can remember if we got have a FPU and use this again in setjmp & co.

> the Boston area want a free 5000/120?

Anybody got me a free Indy power supply ...

  Ralf

---

From: Jun Sun <[email-masked]>
Date: Tue, 17 Oct 2000 21:04:54 -0700

I thank everybody who replied!  My noticable absence in the discussion
is merely an indication of my ignorance on this issue.  But I really
appreciate all the messages I got.

Over the past weekend and yesterday, I started to collect, compile and
package the toolchains.  Here is the first report.

I finally settled down with the old but deemed reliable versions :

a) binutils v2.8.1 + mips patch 

ftp://sourceware.cygnus.com/pub/binutils/releases/
ftp://oss.sgi.com/pub/linux/mips/binutils/binutils-2.8.1-3.diff.gz

b) egcs 1.0.3a + mips patch

ftp://ftp.mvista.com/pub/Area51/mips_le/misc/egcs-1.0.3a.tar.gz
ftp://oss.sgi.com/pub/linux/mips/egcs/egcs-1.0.3a-2.diff.gz

(Ralf, you cannot find egcs-1.0.3a.tar.gz release on the net anymore. 
You probably want to save this file on the same site with the diff
file.)

c) glibc 2.0.6 + mips patch

ftp://oss.sgi.com/pub/linux/mips/glibc/srpms/glibc-2.0.6-5lm.src.rpm

I also had success with latest binutils CVS tree.  I gave a try to the
latest gcc, but did not look into it further.

http://sourceware.cygnus.com/binutils
cvs -z 9 -d :pserver:[email-masked]:/cvs/src co -D "Oct 13,
2000" binutils

-----------

With the above tools, I hooked up with MontaVista's build machine and
generated a few dozens of userland packages.  You can find the RPMS and
SRPMS of the toolchain and applications on the following ftp site. 
Inside these packages you will find a lot of "MontaVista-ism". (yeah,
what a surprise!)

ftp://ftp.mvista.com/pub/Area51/mips_le/

If you have NEC DDB5476 board, you can also try out my kernel on the
following place.  This kernel supports nfs rootfs through on-board ether
port, IDE disk, PS/2 keyboard/mouse, Voodoo3 2000/3000 PCI graphic cards
(framebuffer driver).

ftp://ftp.mvista.com/pub/Area51/ddb-5476/

For your viewing pleasure, I also include a sleek microwindow demo,
which is tested working on DDB5476 board with voodoo3 cards, ps/2
keyboard/mouse.  I have not rpm-lized it yet.  You can find the binaries
on the following place:

ftp://ftp.mvista.com/pub/Area51/mips_le/microwindows

Please note all these packages are my own experimental stuff.  Please do
not call MontaVista's support engineers about bugs or problems.  I will
continue to do some more trials on MIPS toolchains, and post my results.

Thanks again to everyone who replied.

Jun

P.S., The ftp uploading is still running.  It should be completed in one
hour.

---

From: Florian Lohoff <[email-masked]>
Date: Wed, 18 Oct 2000 03:33:50 +0200

> You probably want to save this file on the same site with the diff

You can ...

lftp gcc.cygnus.com:/pub/gcc/old-releases/egcs> ls
egcs-1.0.1.tar.bz2   egcs-1.0.tar.bz2     egcs-1.1b.tar.bz2
egcs-1.0.2.tar.bz2   egcs-1.1.1.tar.bz2   md5.sum
egcs-1.0.3a.tar.bz2  egcs-1.1.2.tar.bz2   patches/

Flo

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 18 Oct 2000 03:57:19 +0200

> You probably want to save this file on the same site with the diff

1.0.3a is part of the srpm packages on oss.

> ftp://oss.sgi.com/pub/linux/mips/glibc/srpms/glibc-2.0.6-5lm.src.rpm

I have a glibc-2.0.6-7lm almost ready, still needs some more testing.

> latest gcc, but did not look into it further.

Same here with a tree that is a few days old.  I haven't yet tried to 
build a kernel but for userland I have no relevant problem compared
to 2.8.1 but tons of fixed ones.

One ancient bug which is about to become a serious one still exist in
gas.  Gas doesn't properly handle branch that exceed the +/- 128kb
range that can be encoded in the 16-bit branch offset.  It should
(SGI's as does) expand the branch as a macro instruction like this:

loop:
	[...]
	beq	r1, r2, loop

should be turned into:

loop:
	[...]
	bnez	r1, r2, 1f
	j	loop
1:

but of course only if the branch destination is outside the 16-bit range.
Thanks to the ever increasing code size there are now several realworld
examples which run into this problem.  Volunteers?

  Ralf

---

From: "Jay Carlson" <[email-masked]>
Date: Tue, 17 Oct 2000 21:59:49 -0400

> few programs like for example mutt2 or bash2 will die therefore.

Ah yes, this has bit me a few times even with my hacked 2.95.2.  I think
this is what the libc-hacker people were talking about in terms of glibc
mistakenly reexporting the exception handing stuff.  I don't remember them
being very happy about it.

> the precense / absence of hardware fp at runtime and behaves accordingly.

I don't think this is necessary for any correctly built and linked
executable.

On platforms with no hardware FPU and no kernel emulation, any main program
or library trying to touch a floating point variable will immediately bomb,
so there is no chance of undiagnosed incorrect behavior.

On machines with FPUs, setjmp/longjmp between modules that disagree on
__HAVE_FPU__ will result in the callee-saved FPU registers not being
saved/restored properly, and that will be a silent failure.  On the other
hand, any intercall between modules where a float as an argument or return
value will silently fail too.

The most plausible failure case I can think of is on a machine with
hardware/kernel FPU.  A softfloat main program calls some kind of hardfloat
plugin .so, solely using integer arguments/return values.  However, the
plugin was built hardfp, and gets upset when the FP control word isn't
initialized...

I dunno.  I just don't see softfp binaries ever showing up on hardfp
platforms, aside from the proposed Linux VR transition to hardfp.

Jay

---

From: Jun Sun <[email-masked]>
Date: Wed, 18 Oct 2000 02:20:42 -0700

> lftp gcc.cygnus.com:/pub/gcc/old-releases/egcs> ls

Darn! I missed the most sensible place ...

On the other hand, if you try to search for egcs-1.0.3a, I bet you will
really have a hard time - I suppose ftp is conveniently forgotten due to
the new, crowded, over-populated web.

Jun

---

From: <[email-masked]>
Date: Tue, 17 Oct 2000 22:25:12 -0400 (EDT)

www.google.com
heh, I wonder how many geeks declare their love of google every day?
	Nick

---

From: Florian Lohoff <[email-masked]>
Date: Wed, 18 Oct 2000 11:18:24 +0200

> the new, crowded, over-populated web.

Try http://ftpsearch.ntnu.no

It returns a couple of hundrets of links 

BTW: Does anyone still use archie ? I just installed it after 
years of non usage and i guess i have problems finding
an archie server :)

Flo

---

From: Florian Lohoff <[email-masked]>
Date: Wed, 18 Oct 2000 14:30:03 +0200

> examples which run into this problem.  Volunteers?

By thinking about this without any knowledge of the binutils code generation.

How does this work if loop is only an external symbol ? The distance
will than be relevant when linking but then the code will already be there
and one would need to insert an instruction.

Flo

---

From: Geert Uytterhoeven <[email-masked]>
Date: Wed, 18 Oct 2000 13:42:20 +0200 (CEST)

> following place.  This kernel supports nfs rootfs through on-board ether

Was it difficult to get the builtin Ethernet working? I mean, is it now
trivial to get it to work on the ddb5074 as well? I'm still not at work, so I
cannot play with^H^H^H^H^H^H^H^H^Hwork on it myself.

> port, IDE disk, PS/2 keyboard/mouse, Voodoo3 2000/3000 PCI graphic cards

Cool! Graphics!

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- [email-masked]

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds

---

From: Jun Sun <[email-masked]>
Date: Wed, 18 Oct 2000 10:15:04 -0700

> cannot play with^H^H^H^H^H^H^H^H^Hwork on it myself.

It was a tough problem, and it took me a long time to figure out. 
Basically, the srom only contains mac address - no check sum nor media
tables.  You need to by pass the checksum checking and eeprom parsing in
the driver code.  In addition, I have to reset the tulip chip at the
board startup time.  I use pmon to do the downloading.  Pmon must have
set the chip in some state that the linux driver cannot successfully
re-initialize it by default.

I also layout the PCI memory space idential to the physical memory
space, ie., system ram starts from 0.  I was concerned some drivers
don't do address translations between these two address spaces.

I actually have a DDB5074 board myself.  I can try it out myself, but I
am a little lazy to do that - not sure if anybody is still interested in
that board.

> > port, IDE disk, PS/2 keyboard/mouse, Voodoo3 2000/3000 PCI graphic cards

It is fun to have graphics.  Yesterday I got hold of a MediaQ 200 card
and a fb driver for it.  It works like a charm.

Jun

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 18 Oct 2000 14:27:48 +0200

> years of non usage and i guess i have problems finding

Dark memories tell me archie.funet.fi, archie.uni-erlangen.de, somewhere at
sunet.se, [email-masked] (email, dunno if it was also telnet accessible).

  Ralf

---

From: Ralf Baechle <[email-masked]>
Date: Wed, 18 Oct 2000 22:31:03 +0200

> being very happy about it.

It's FAQ.  In short their answer is to not use a newer compiler than
egcs 2.7.2 (or was it 2.8.1?).  Hardly acceptable for us.  Anyway, glibc 2.2
cleans up with that; a few programs need recompiling and where this is
not an option there is a small library that can be pre-loaded and which
will satisfy any references.

> platforms, aside from the proposed Linux VR transition to hardfp.

Ok.  Then we just need to make sure that people don't mix objects.

  Ralf

---

From: Ralf Baechle <[email-masked]>
Date: Thu, 19 Oct 2000 00:37:02 +0200

> and one would need to insert an instruction.

Branches to external symbols aren't allowed with MIPS ELF objects.

  Ralf

---

From: Andreas Jaeger <[email-masked]>
Date: 20 Oct 2000 13:09:35 +0200

I'd like to add the following paragraph to the glibc2 FAQ.  Is this
correct?

Btw. I've updated my www page.

Andreas

??mips	Which tools should I use for MIPS?

{AJ} Either use as compiler egcs 1.1.2 or the current development version of
gcc 2.96 from CVS.  gcc 2.95.x does not work correctly on mips-linux.

You need recent binutils, anything before and including 2.10 will not work
correctly.  Either try the Linux binutils 2.10.0.26 from HJ Lu or the
current development version of binutils.

For details check also my page <http://www.suse.de/~aj/glibc-mips.html>.

-- 
 Andreas Jaeger
  SuSE Labs [email-masked]
   private [email-masked]
    http://www.suse.de/~aj

---

From: "Jay Carlson" <[email-masked]>
Date: Fri, 20 Oct 2000 08:03:24 -0400

> gcc 2.96 from CVS.  gcc 2.95.x does not work correctly on mips-linux.

Why not 1.0.3a+patches?  And could you mention a day that a 2.97 checkout
was known to work?

Jay

---

From: Geert Uytterhoeven <[email-masked]>
Date: Fri, 20 Oct 2000 16:55:44 +0200 (CEST)

> tables.  You need to by pass the checksum checking and eeprom parsing in

Having worked on Tulip drivers for the DDB (for another OS), I was already 
ware of that.

> re-initialize it by default.

Ah, so  that's the big problem! I never bothered to try resetting the Tulip.

Gr{oetje,eeting}s,

						Geert

---

From: Ralf Baechle <[email-masked]>
Date: Sat, 21 Oct 2000 03:24:44 +0200

> Why not 1.0.3a+patches?  And could you mention a day that a 2.97 checkout

1.0.3a doesn't work for compiling glibc 2.1.94 on any architecture due to
a bug in the handling of weak undefined symbols - they're emitted as
strong symbols.

  Ralf