init fails w/ new build of gcc & glibc

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/

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/

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 [off-list ref]
MontaVista Software, Inc.

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

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/

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/

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/

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 [off-list ref]
MontaVista Software, Inc.

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

At 05:22 PM 8/17/2001 -0500, Mark Hatle wrote:

quoted

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.)

quoted

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/

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/

At 06:15 PM 8/17/2001 -0500, Mark Hatle wrote:

quoted

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/