init fails w/ new build of gcc & glibc

init fails w/ new build of gcc & glibc

[Mark Pilon]

Hi,

I'm attempting to build gcc for powerPC as well as new binutils &
glibc, -- all in an attempt to support a new 4xx chip w/ floating
point.

I'm using HHL 1.2 for the 405 & walnut as my base and am attempting
to start using the new compiler and libraries:

I've recompiled the kernel w/ the new compiler (albeit -msoft-float)
and it boots fine;

running w/ the hhl 1.2 libraries the whole system runs fine;

supplying all of the libraries built under the new glibc causes the
following when init is spawned:

Kernel panic: Attempted to kill init!
init: error while loading shared libraries: cannot open sh ared object file:
cannot load shared object file: No such file or directory

-- there is no comment as to what's missing ...

I can spawn sash in place of 'init' and that runs (no surprise ...)
-- I realize I've probably screwed up something pretty basic --
I'm probably out of synch somewhere in the libraries but don't
know how to debug this further.

under sash, when I try to -exec /bin/ldd /bin/busybox all I get
is a file-not-found for ldd ...

thanks in advance,

Mark

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

Re: init fails w/ new build of gcc & glibc

[Mark Hatle]

Mark Pilon wrote:
>
> Hi,
>
> I'm attempting to build gcc for powerPC as well as new binutils &
> glibc, -- all in an attempt to support a new 4xx chip w/ floating
> point.
>
> I'm using HHL 1.2 for the 405 & walnut as my base and am attempting
> to start using the new compiler and libraries:
>
> I've recompiled the kernel w/ the new compiler (albeit -msoft-float)
> and it boots fine;
>
> running w/ the hhl 1.2 libraries the whole system runs fine;
>
> supplying all of the libraries built under the new glibc causes the
> following when init is spawned:
>
> Kernel panic: Attempted to kill init!
> init: error while loading shared libraries: cannot open sh ared object file:
> cannot load shared object file: No such file or directory
>
> -- there is no comment as to what's missing ...
>
> I can spawn sash in place of 'init' and that runs (no surprise ...)
> -- I realize I've probably screwed up something pretty basic --
> I'm probably out of synch somewhere in the libraries but don't
> know how to debug this further.

A question... is the floating point standard PowerPC floating point?  or
is it "special" for your application?

If the answer is that it is standard floating point then you can use the
"7xx" or "82xx" tools for your project.  If you want to recompile then
you need to recompile the whole system from the compilers up to glibc
and all of the apps.  There are two ABIs, one for soft-floating point
and one for hard floating point.  They are not run-time compatable.

If the part is using non-standard PPC floating point then you will need
to run soft-floating point, or implement all of the instructions in both
binutils and gcc, and make corresponding changes to glibc.  (A lot of
work.)

--Mark

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

Re: init fails w/ new build of gcc & glibc

[Dr. Craig Hollabaugh]

At 04:48 PM 8/17/2001 -0500, Mark Hatle wrote:
>If the answer is that it is standard floating point then you can use the
>"7xx" or "82xx" tools for your project.  If you want to recompile then
>you need to recompile the whole system from the compilers up to glibc
>and all of the apps.  There are two ABIs, one for soft-floating point
>and one for hard floating point.  They are not run-time compatable.

Mark,

You mentioned these two exclusive ABIs a couple days ago. If you want to compile the toolchain and the kernel correctly to insure run-time compatibility (in my case for 8xx), would you do this

for kernel fp emulation
compile kernel with CONFIG_MATH_EMULATION=y, (do you use -msoft-float while compiling kernel?)
then compile the toolchain without -msoft-float

or

for soft-floating point - no kernel emulation
compile kernel CONFIG_MATH_EMULATION is not set (do you use -msoft-float while compiling kernel?)
then compile the toolchain with -msoft-float


Very very curious
Thanks
Craig


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

Re: init fails w/ new build of gcc & glibc

[Mark Hatle]

> Mark,
>
> You mentioned these two exclusive ABIs a couple days ago. If you want to compile the
> toolchain and the kernel correctly to insure run-time compatibility (in my case for 8xx),
> would you do this
>
> for kernel fp emulation
> compile kernel with CONFIG_MATH_EMULATION=y, (do you use -msoft-float while compiling
> kernel?)
> then compile the toolchain without -msoft-float

Use the kernel parameters as they stand, I wouldn't mess with them....
(floating point is not supposed to happen in the kernel anyway, and when
it does it's almost always assembly that is trapped anyway.)

> or
>
> for soft-floating point - no kernel emulation
> compile kernel CONFIG_MATH_EMULATION is not set (do you use -msoft-float while compiling kernel?)
> then compile the toolchain with -msoft-float

Basically.. One thing to keep in mind on the 8xx (due to cache line
size) it'll never truely be compatable with the rest of the PPC world.
But on a processor like the 405 it "can be" compatable using the
CONFIG_MATH_EMULATION.  The catch is that you have a lot more overhead
doing emulation.... (The emulation itself is pretty fast, certainly no
slower then the software code invoked in -msoft-float..)  However, you
have much more context switching over head and possible cache
invalidation.  Also, your software could be using floating point
registers w/o you expliciting using float's or double's due to gcc
optimizations to argument passing.  All in all you will have a penalty
for using hard floating point on a soft-floating point architecture.

This is the reason that MontaVista has chosen to go the route of
soft-float...

--Mark

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

Re: init fails w/ new build of gcc & glibc

[Joe Green]

Mark Hatle wrote:
> But on a processor like the 405 it "can be" compatable using the
> CONFIG_MATH_EMULATION.  The catch is that you have a lot more overhead
> doing emulation.... (The emulation itself is pretty fast, certainly no
> slower then the software code invoked in -msoft-float..)

In theory, the compiler can also optimize user-space emulation better
(move code around, use different registers).  In practice, I don't know
that this has a significant effect.

--
Joe Green <jgreen@mvista.com>
MontaVista Software, Inc.

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

Re: init fails w/ new build of gcc & glibc

[Dr. Craig Hollabaugh]

At 05:22 PM 8/17/2001 -0500, Mark Hatle wrote:
>> Mark,
>>
>> You mentioned these two exclusive ABIs a couple days ago. If you want to compile the
>> toolchain and the kernel correctly to insure run-time compatibility (in my case for 8xx),
>> would you do this
>>
>> for kernel fp emulation
>> compile kernel with CONFIG_MATH_EMULATION=y, (do you use -msoft-float while compiling
>> kernel?)
>> then compile the toolchain without -msoft-float
>
>Use the kernel parameters as they stand, I wouldn't mess with them....
>(floating point is not supposed to happen in the kernel anyway, and when
>it does it's almost always assembly that is trapped anyway.)
>
>> or
>>
>> for soft-floating point - no kernel emulation
>> compile kernel CONFIG_MATH_EMULATION is not set (do you use -msoft-float while compiling kernel?)
>> then compile the toolchain with -msoft-float
>
>Basically.. One thing to keep in mind on the 8xx (due to cache line
>size) it'll never truely be compatable with the rest of the PPC world.
>But on a processor like the 405 it "can be" compatable using the
>CONFIG_MATH_EMULATION.  The catch is that you have a lot more overhead
>doing emulation.... (The emulation itself is pretty fast, certainly no
>slower then the software code invoked in -msoft-float..)  However, you
>have much more context switching over head and possible cache
>invalidation.  Also, your software could be using floating point
>registers w/o you expliciting using float's or double's due to gcc
>optimizations to argument passing.  All in all you will have a penalty
>for using hard floating point on a soft-floating point architecture.
>
>This is the reason that MontaVista has chosen to go the route of
>soft-float...





To summarize for me (and others), "leave kernel parameters as they stand" means

CONFIG_MATH_EMULATION=y and compile with -msoft-float

"MontaVista has chosen to go the route of soft-float..." means that MontaVista's tools are compiled with -msoft-float and --without-fp. I should compile my apps and toolchain (or use MV's) the same way.


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

Re: init fails w/ new build of gcc & glibc

[Mark Hatle]

> To summarize for me (and others), "leave kernel parameters as they stand" means
>
> CONFIG_MATH_EMULATION=y and compile with -msoft-float

If the kernel source uses -msoft-float leave it, if it does not leave
it.. ;)  Don't fool with kernel CFLAGS unless you _REALLY_ know what you
are doing.

--Mark

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

Re: init fails w/ new build of gcc & glibc

[Dr. Craig Hollabaugh]

At 06:15 PM 8/17/2001 -0500, Mark Hatle wrote:
>> To summarize for me (and others), "leave kernel parameters as they stand" means
>>
>> CONFIG_MATH_EMULATION=y and compile with -msoft-float
>
>If the kernel source uses -msoft-float leave it, if it does not leave
>it.. ;)  Don't fool with kernel CFLAGS unless you _REALLY_ know what you
>are doing.


OK, you got it.  Thanks for the help, have a great weekend!


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

Re: init fails w/ new build of gcc & glibc

[Joe Green]

Mark Pilon wrote:
> running w/ the hhl 1.2 libraries the whole system runs fine;
>
> supplying all of the libraries built under the new glibc causes the
> following when init is spawned:
>
> Kernel panic: Attempted to kill init!
> init: error while loading shared libraries: cannot open sh ared object file:
> cannot load shared object file: No such file or directory

Are you saying you took user-space packages built for soft floating
point and replaced glibc with one built for hard fp?  If so, that's
your problem.  There are ABI changes between hard and soft fp; you
can't mix and match.

--
Joe Green <jgreen@mvista.com>
MontaVista Software, Inc.

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

Re: init fails w/ new build of gcc & glibc

[Dr. Craig Hollabaugh]

At 02:47 PM 8/17/2001 -0600, Mark Pilon wrote:
>running w/ the hhl 1.2 libraries the whole system runs fine;
>
>supplying all of the libraries built under the new glibc causes the
>following when init is spawned:


Did you set the prefix to / on the glibc configure line then do a make

install_root=/somelibdirectoryforyournewrootfs

you can do this or...

in your new root filesystem something like this in your /usr/powerpc-linux/lib

ln -s ../../lib lib


the glibs have absolute path info in them, so either reconfigure and recompile for
your rootfs using prefix=/ (make sure you use install_root when you make install) or
make a link.

Hope this helps.

Craig
ps. I'm going down this very road, let's talk.



___________________________________________________________
Dr. Craig Hollabaugh                           craig@hollabaugh.com
304 6th Avenue, P.O. Box 1405
Ouray, CO 81427-1405                       See my "kitchen sink" resume at
970 325 0319 home                                  www.hollabaugh.com/resume.html
970 325 0509 office
215 882 1880 cell


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