Compiling glibc-2.3.2 (debian) on mpc8xx ;-)

Compiling glibc-2.3.2 (debian) on mpc8xx ;-)

[David Jander]

Hi all,

I proudly announce that we finally have the first two prototypes of our boards
based on the MPC852T running. Until now it looks like one of those lucky
"one-time-right" designs, since it went flawless until now. We have 64 MByte
SDRAM on-board, an ethernet Phy (FEC), 4 Mbyte Flash, etc...
Since I'm quite crazy, and love running "big-stuff" on "small-things" I
decided to install Debian-unstable (sid) on an nfs-mounted root.
So far, so good. I compiled a kernel with FPU-emulation just in case, and went
through the installation of the base system using glibc-2.3.1 from ELDK
binaries plugged on top of the version from debian, to avoid further
incompatibilities.
Now, after apt-getting a hell of a lot of fancy software (all running quite
fine until now - except floating-point-libc stuff), the time has come to
recompile GlibC..... on the target!

Question: What do I have to patch exactly before compiling? I want to leave
floating-point stuff in there for now to stay compatible with
debian-binaries. AFAIK there is (was?) an issue with
sysdeps/powerpc/powerpc32/memset.S and sysdeps/powerpc/powerpc32/dl-machine.c
containing code that assumed a cache-line of different size than that of the
MPC8xx. Is this still the case in glibc-2.3.2? Hasn't this been patched in
the official sources?
What else do I have to look out for? What other patches to apply? Where to get
them from?

Greetings,

--
David Jander
Protonic Holland.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Compiling glibc-2.3.2 (debian) on mpc8xx ;-)

[Wolfgang Denk]

In message <200403090953.54598.david.jander@protonic.nl> you wrote:
>
> So far, so good. I compiled a kernel with FPU-emulation just in case, and went
> through the installation of the base system using glibc-2.3.1 from ELDK
> binaries plugged on top of the version from debian, to avoid further
> incompatibilities.

You have just created a bunch of incompatibilities here.  You  cannot
use binaries and shared libraries that don't fit to each other.

> Question: What do I have to patch exactly before compiling? I want to leave
> floating-point stuff in there for now to stay compatible with

What do you mean by "leave floating-point stuff in"?

Since the MPC8xx does  not  have  a  FPU,  you  cannot  use  hardware
floating  point. Oh yes, there is the FP emulation in the kernel. But
this has never been working reliably.

> debian-binaries. AFAIK there is (was?) an issue with
> sysdeps/powerpc/powerpc32/memset.S and sysdeps/powerpc/powerpc32/dl-machine.c
> containing code that assumed a cache-line of different size than that of the
> MPC8xx. Is this still the case in glibc-2.3.2? Hasn't this been patched in
> the official sources?
> What else do I have to look out for? What other patches to apply? Where to get
> them from?

See the patches in the ELDK build environment.


Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
The greatest threat towards future is indifference.

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/

Re: Compiling glibc-2.3.2 (debian) on mpc8xx ;-)

[Wolfgang Denk]

In message <200403091240.40660.david.jander@protonic.nl> you wrote:
> >
> > You have just created a bunch of incompatibilities here.  You  cannot
> > use binaries and shared libraries that don't fit to each other.
>
> I know. Strange thing is: it kinda works fine... until you hit code with
> calles to FP-related functions in the library. For example the following does

No. it does not work at all fine. It just does not crash immediately,
and some errors my be subtle and go through unnoticed.

> The math works fine, but printf screws up.

You re just lucky and working on a slightly  loaded  system  if  this
appears to be fine.

> Another observation: while "ps aux" shows correct percentage numbers (FP I
> assume), "top" shows only "nan" values for CPU and memory. Any explanation to
> why "ps" works fine?  I haven't looked at the sources yet.

I don't care. What you see is undefined behaviour, and you know that.

> > floating  point. Oh yes, there is the FP emulation in the kernel. But
> > this has never been working reliably.
>
> Wow! That sounds strong! How comes that? What are we waiting to get it working
> better? I assume the emulation on this processor works similar to the 386
> through exception handling, am I right?

You are right.

Simply: it does  not  make  sense  to  spend  effort  in  fixing  the
remainingproblems   since   this   is  so  awafully  slow  and  using
-msoft-float on bianries and libraries is a mauch better way to  deal
with the FP problem.

> Can I leave the patches involving FP-stuff out and rely on emulation? I guess

IMHO you cannot rely  on  the  emulation  at  all.  It  never  wroked
reliably in our tests.

> not for what you said earlier, but if the emulation worked well enough,
> whouldn't that be enough? Of course it will be slow as hell, but speed is not
> as important as actually running the code.

If "running" the code includes a certain level of reliability I would
not try to do that.

Best regards,

Wolfgang Denk

--
Software Engineering:  Embedded and Realtime Systems,  Embedded Linux
Phone: (+49)-8142-4596-87  Fax: (+49)-8142-4596-88  Email: wd@denx.de
Winners never talk about glorious victories. That's  because  they're
the  ones  who  see  what the battlefield looks like afterwards. It's
only the losers who have glorious victories.
                                      - Terry Pratchett, _Small Gods_

** Sent via the linuxppc-embedded mail list. See http://lists.linuxppc.org/