cross-compiling & debugging embedded-linux apps

cross-compiling & debugging embedded-linux apps

[Brendan J Simon]

I have a powerpc embedded system (MPC860, 4MB Flash, 16MB RAM, ethernet,
rs232).  I have compiled the kernel and can boot it using a root
filesystem via initrd or nfs.  The root filesystem is a minimal one that
was on the linuxppc-embedded ftp site.  It basically has /bin/sh,
/bin/ls and a few libraries in /lib.

I NEED to be able to compile apps from the sources.  I have managed to
cross-compile ncurses and bash.  I can't get bash to run at all (even a
statically compiled version).  I get segmentaion faults.  I'm currently
using SASH which I have cross-compiled as a static binary.  I compiled a
test app (bjs1.c) which outputs a string every second.  It is compiled
as a static binary (bjs1-static) and a shared binary (bjs1-shared).  The
static binary works but the shared one does not.  I assume it is some
library problem but I can't figure out what.  The output of the sash
session is below.

Stand-alone shell (version 1.0)
> ./bjs1-static
BJS1: Brendan was here
BJS1: Brendan was here
BJS1: Brendan was here
pid 7: killed (signal 2)
>
> ./bjs1-shared
pid 8: killed (signal 11)
>

I have all the libraries on the root filesystem.  The rpc.nfsd daemon
seems to read the entire file but sash says the process is killed with
signal 11 (segmentation fault).  I have no idea how to debug this.  I
don't think there is a simulator for the mpc860 as part of gdb.  Is
there a way of debugging this on the target with powerpc-gdb and an
ethernet or serial connection ?

How does the kernel know where to look for libraries ?  I assume there
are some default locations like /lib.  I haven't got an ld.so.conf setup
nor do I have ldconfig.

It can't be that hard to get a simple 10 line program to execute as a
shared binary.  It must be something really simple that I am missing.

Thanks for any help,
Brendan Simon.


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

Re: cross-compiling & debugging embedded-linux apps

[Alan Mimms]

You know about the ldd command?  Do 'ldd bjs1-shared' to see what 
libraries you need for your shared executable and make sure they're 
there and built with no floating point.  When you compile and link, 
you're using '-mcpu=860' or '-msoft-float', right?  That also could be 
a problem for you.

I think the seg fault is what Dan's kernel maps the floating point 
handler's exception to - it's really a floating point exception.  I 
COULD be wrong about this.  It's one fo the things I have been meaning 
to look into but haven't yet had the chance.

(Caveat emptor on the above - I'm just a beginner myself.)

a

>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 12/30/99, 8:50:29 PM, Brendan J Simon <Brendan.Simon@ctam.com.au> 
wrote regarding cross-compiling & debugging embedded-linux apps:


> I have a powerpc embedded system (MPC860, 4MB Flash, 16MB RAM, 
ethernet,
> rs232).  I have compiled the kernel and can boot it using a root
> filesystem via initrd or nfs.  The root filesystem is a minimal one 
that
> was on the linuxppc-embedded ftp site.  It basically has /bin/sh,
> /bin/ls and a few libraries in /lib.

> I NEED to be able to compile apps from the sources.  I have managed to
> cross-compile ncurses and bash.  I can't get bash to run at all (even 
a
> statically compiled version).  I get segmentaion faults.  I'm 
currently
> using SASH which I have cross-compiled as a static binary.  I compiled 
a
> test app (bjs1.c) which outputs a string every second.  It is compiled
> as a static binary (bjs1-static) and a shared binary (bjs1-shared).  
The
> static binary works but the shared one does not.  I assume it is some
> library problem but I can't figure out what.  The output of the sash
> session is below.

> Stand-alone shell (version 1.0)
> > ./bjs1-static
> BJS1: Brendan was here
> BJS1: Brendan was here
> BJS1: Brendan was here
> pid 7: killed (signal 2)
> >
> > ./bjs1-shared
> pid 8: killed (signal 11)
> >

> I have all the libraries on the root filesystem.  The rpc.nfsd daemon
> seems to read the entire file but sash says the process is killed with
> signal 11 (segmentation fault).  I have no idea how to debug this.  I
> don't think there is a simulator for the mpc860 as part of gdb.  Is
> there a way of debugging this on the target with powerpc-gdb and an
> ethernet or serial connection ?

> How does the kernel know where to look for libraries ?  I assume there
> are some default locations like /lib.  I haven't got an ld.so.conf 
setup
> nor do I have ldconfig.

> It can't be that hard to get a simple 10 line program to execute as a
> shared binary.  It must be something really simple that I am missing.

> Thanks for any help,
> Brendan Simon.


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

Re: cross-compiling & debugging embedded-linux apps

[Jim Lewis]

Alan Mimms wrote:

> You know about the ldd command?  Do 'ldd bjs1-shared' to see what
> libraries you need for your shared executable and make sure they're
> there and built with no floating point.  When you compile and link,
> you're using '-mcpu=860' or '-msoft-float', right?  That also could be
> a problem for you.
>
> I think the seg fault is what Dan's kernel maps the floating point
> handler's exception to - it's really a floating point exception.

On the MPC8xx, the only vector invoked for Floating Point is the Software
Emulation Interrupt, vector 0x1000. SIGSEGV is issued as a result of Machine
Check exception, vector 0x200.

> I COULD be wrong about this.  It's one fo the things I have been meaning
> to look into but haven't yet had the chance.
>
> (Caveat emptor on the above - I'm just a beginner myself.)
>
> a
>
> >>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<
>
> On 12/30/99, 8:50:29 PM, Brendan J Simon <Brendan.Simon@ctam.com.au>
> wrote regarding cross-compiling & debugging embedded-linux apps:
>
> > I have a powerpc embedded system (MPC860, 4MB Flash, 16MB RAM,
> ethernet,
> > rs232).  I have compiled the kernel and can boot it using a root
> > filesystem via initrd or nfs.  The root filesystem is a minimal one
> that
> > was on the linuxppc-embedded ftp site.  It basically has /bin/sh,
> > /bin/ls and a few libraries in /lib.
>
> > I NEED to be able to compile apps from the sources.  I have managed to
> > cross-compile ncurses and bash.  I can't get bash to run at all (even
> a
> > statically compiled version).  I get segmentaion faults.  I'm
> currently
> > using SASH which I have cross-compiled as a static binary.  I compiled
> a
> > test app (bjs1.c) which outputs a string every second.  It is compiled
> > as a static binary (bjs1-static) and a shared binary (bjs1-shared).
> The
> > static binary works but the shared one does not.  I assume it is some
> > library problem but I can't figure out what.  The output of the sash
> > session is below.
>
> > Stand-alone shell (version 1.0)
> > > ./bjs1-static
> > BJS1: Brendan was here
> > BJS1: Brendan was here
> > BJS1: Brendan was here
> > pid 7: killed (signal 2)
> > >
> > > ./bjs1-shared
> > pid 8: killed (signal 11)
> > >
>
> > I have all the libraries on the root filesystem.  The rpc.nfsd daemon
> > seems to read the entire file but sash says the process is killed with
> > signal 11 (segmentation fault).  I have no idea how to debug this.  I
> > don't think there is a simulator for the mpc860 as part of gdb.  Is
> > there a way of debugging this on the target with powerpc-gdb and an
> > ethernet or serial connection ?
>
> > How does the kernel know where to look for libraries ?  I assume there
> > are some default locations like /lib.  I haven't got an ld.so.conf
> setup
> > nor do I have ldconfig.
>
> > It can't be that hard to get a simple 10 line program to execute as a
> > shared binary.  It must be something really simple that I am missing.
>
> > Thanks for any help,
> > Brendan Simon.

--
Jim Lewis
Sr. Field Applications Engineer
MontaVista Software, Inc.
(817)261-9088 http://www.mvista.com


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

Re: cross-compiling & debugging embedded-linux apps

[Brendan J Simon]

Jim Lewis wrote:

> Alan Mimms wrote:
>
> > You know about the ldd command?  Do 'ldd bjs1-shared' to see what
> > libraries you need for your shared executable and make sure they're
> > there and built with no floating point.  When you compile and link,

Yep, but ldd doesn't seem to exist in my cross-tools.  Is it part of gcc,
binutils or some other package ?


> > you're using '-mcpu=860' or '-msoft-float', right?  That also could be
> > a problem for you.

I'm using -mcpu=860 but I am not specifying -msoft-float.  This shouldn't be a
problem for a simple program that continuously prints out a string using puts().
The static version runs so it is some kind of dynamic library loader problem I
suspect.

I've had some replies from the cross-gcc mailing list with some suggestions.
I'll post any results worth mentioning.

Thanks,
Brendan Simon.


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

Re: cross-compiling & debugging embedded-linux apps

[Alan Mimms]

You might want to use objdump -p on the file as suggested in an 
earlier post here today.  I think that's effectively like ldd's output 
only more so.

a

>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 1/3/00, 4:30:49 PM, Brendan J Simon <Brendan.Simon@ctam.com.au> wrote 
regarding Re: cross-compiling & debugging embedded-linux apps:


> Jim Lewis wrote:

> > Alan Mimms wrote:
> >
> > > You know about the ldd command?  Do 'ldd bjs1-shared' to see what
> > > libraries you need for your shared executable and make sure they're
> > > there and built with no floating point.  When you compile and link,

> Yep, but ldd doesn't seem to exist in my cross-tools.  Is it part of 
gcc,
> binutils or some other package ?


> > > you're using '-mcpu=860' or '-msoft-float', right?  That also could be
> > > a problem for you.

> I'm using -mcpu=860 but I am not specifying -msoft-float.  This 
shouldn't be a
> problem for a simple program that continuously prints out a string 
using puts().
> The static version runs so it is some kind of dynamic library loader 
problem I
> suspect.

> I've had some replies from the cross-gcc mailing list with some 
suggestions.
> I'll post any results worth mentioning.

> Thanks,
> Brendan Simon.


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

Re: cross-compiling & debugging embedded-linux apps

[Jim Lewis]

Brendan J Simon wrote:

> I have a powerpc embedded system (MPC860, 4MB Flash, 16MB RAM, ethernet,
> rs232).  I have compiled the kernel and can boot it using a root
> filesystem via initrd or nfs.  The root filesystem is a minimal one that
> was on the linuxppc-embedded ftp site.  It basically has /bin/sh,
> /bin/ls and a few libraries in /lib.
>
> I NEED to be able to compile apps from the sources.  I have managed to
> cross-compile ncurses and bash.  I can't get bash to run at all (even a
> statically compiled version).  I get segmentaion faults.  I'm currently
> using SASH which I have cross-compiled as a static binary.  I compiled a
> test app (bjs1.c) which outputs a string every second.  It is compiled
> as a static binary (bjs1-static) and a shared binary (bjs1-shared).  The
> static binary works but the shared one does not.  I assume it is some
> library problem but I can't figure out what.

I think you are right. What libraries are you linking against? I think the the
minroot FS from the embedded FTP site uses libc 1.99. I have had nothing but
trouble when trying to mix libraries.

If you did build against different libraries, one way you could do is to
create a new directory for your shared application and the shared objects you
linked against. Make sure to include the ld.so.1 executable. Then, at the
target SASH prompt, issue the following:
> /test/ld.so.1 --library-path /test /test/bjs1-shared

> The output of the sash
> session is below.
>
> Stand-alone shell (version 1.0)
> > ./bjs1-static
> BJS1: Brendan was here
> BJS1: Brendan was here
> BJS1: Brendan was here
> pid 7: killed (signal 2)
> >
> > ./bjs1-shared
> pid 8: killed (signal 11)
> >
>
> I have all the libraries on the root filesystem.  The rpc.nfsd daemon
> seems to read the entire file but sash says the process is killed with
> signal 11 (segmentation fault).  I have no idea how to debug this.  I
> don't think there is a simulator for the mpc860 as part of gdb.  Is
> there a way of debugging this on the target with powerpc-gdb and an
> ethernet or serial connection ?

Yes, there is. Dan posted some gdbserver sources a while back. That allows you
to do cross debug. But you are likely to have the same problems building
gdbserver that you are having with your simple test application.

>
>
> How does the kernel know where to look for libraries ?  I assume there
> are some default locations like /lib.  I haven't got an ld.so.conf setup
> nor do I have ldconfig.

The 'default' location seems to be built in to the executable. Usually,
/lib/ld.so.1 is invoked and it tries to open ld.so.cache to determine where
libraries are. If it cannot find /etc/ld.so.cache, then it just uses default
locations that were "compiled in". The ld.so.cache is created by ldconfig,
which reads ld.so.conf to determine how to build ld.so.cache.

>
>
> It can't be that hard to get a simple 10 line program to execute as a
> shared binary.  It must be something really simple that I am missing.
>
> Thanks for any help,
> Brendan Simon.

--
Jim Lewis
Sr. Field Applications Engineer
MontaVista Software, Inc.
(817)261-9088 http://www.mvista.com


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

Re: cross-compiling & debugging embedded-linux apps

[Jeff Millar]

----- Original Message -----
From: "Jim Lewis" <jlewis@mvista.com>
>
> Yes, there is. Dan posted some gdbserver sources a while back. That allows
you
> to do cross debug. But you are likely to have the same problems building
> gdbserver that you are having with your simple test application.

gdbserver built fine using -static on our linuxppc 1999 Q3 power mac system.


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

Re: cross-compiling & debugging embedded-linux apps

[Alan Mimms]

I had pretty good luck running gdb on the target with my sources NFS 
mounted.  You can talk to its command line from a telnet window, which 
is pretty acceptable unless you're addicted to those eye-candy GUIs 
that smear lipstick on the gdb chicken...<g>

a

>>>>>>>>>>>>>>>>>> Original Message <<<<<<<<<<<<<<<<<<

On 12/31/99, 8:28:50 AM, Jim Lewis <jlewis@mvista.com> wrote regarding 
Re: cross-compiling & debugging embedded-linux apps:


> Brendan J Simon wrote:

> > I have a powerpc embedded system (MPC860, 4MB Flash, 16MB RAM, 
ethernet,
> > rs232).  I have compiled the kernel and can boot it using a root
> > filesystem via initrd or nfs.  The root filesystem is a minimal one 
that
> > was on the linuxppc-embedded ftp site.  It basically has /bin/sh,
> > /bin/ls and a few libraries in /lib.
> >
> > I NEED to be able to compile apps from the sources.  I have managed to
> > cross-compile ncurses and bash.  I can't get bash to run at all (even 
a
> > statically compiled version).  I get segmentaion faults.  I'm 
currently
> > using SASH which I have cross-compiled as a static binary.  I compiled 
a
> > test app (bjs1.c) which outputs a string every second.  It is compiled
> > as a static binary (bjs1-static) and a shared binary (bjs1-shared).  
The
> > static binary works but the shared one does not.  I assume it is some
> > library problem but I can't figure out what.

> I think you are right. What libraries are you linking against? I think 
the the
> minroot FS from the embedded FTP site uses libc 1.99. I have had 
nothing but
> trouble when trying to mix libraries.

> If you did build against different libraries, one way you could do is 
to
> create a new directory for your shared application and the shared 
objects you
> linked against. Make sure to include the ld.so.1 executable. Then, at 
the
> target SASH prompt, issue the following:
> > /test/ld.so.1 --library-path /test /test/bjs1-shared

> > The output of the sash
> > session is below.
> >
> > Stand-alone shell (version 1.0)
> > > ./bjs1-static
> > BJS1: Brendan was here
> > BJS1: Brendan was here
> > BJS1: Brendan was here
> > pid 7: killed (signal 2)
> > >
> > > ./bjs1-shared
> > pid 8: killed (signal 11)
> > >
> >
> > I have all the libraries on the root filesystem.  The rpc.nfsd daemon
> > seems to read the entire file but sash says the process is killed with
> > signal 11 (segmentation fault).  I have no idea how to debug this.  I
> > don't think there is a simulator for the mpc860 as part of gdb.  Is
> > there a way of debugging this on the target with powerpc-gdb and an
> > ethernet or serial connection ?

> Yes, there is. Dan posted some gdbserver sources a while back. That 
allows you
> to do cross debug. But you are likely to have the same problems 
building
> gdbserver that you are having with your simple test application.

> >
> >
> > How does the kernel know where to look for libraries ?  I assume there
> > are some default locations like /lib.  I haven't got an ld.so.conf 
setup
> > nor do I have ldconfig.

> The 'default' location seems to be built in to the executable. 
Usually,
> /lib/ld.so.1 is invoked and it tries to open ld.so.cache to determine 
where
> libraries are. If it cannot find /etc/ld.so.cache, then it just uses 
default
> locations that were "compiled in". The ld.so.cache is created by 
ldconfig,
> which reads ld.so.conf to determine how to build ld.so.cache.

> >
> >
> > It can't be that hard to get a simple 10 line program to execute as a
> > shared binary.  It must be something really simple that I am missing.
> >
> > Thanks for any help,
> > Brendan Simon.

> --
> Jim Lewis
> Sr. Field Applications Engineer
> MontaVista Software, Inc.
> (817)261-9088 http://www.mvista.com


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

Re: cross-compiling & debugging embedded-linux apps

[Kai Ruottu]

Brendan J Simon wrote:
> 
> I have a powerpc embedded system (MPC860, 4MB Flash, 16MB RAM, ethernet,
> rs232).  I have compiled the kernel and can boot it using a root
> filesystem via initrd or nfs.  The root filesystem is a minimal one that
> was on the linuxppc-embedded ftp site.  It basically has /bin/sh,
> /bin/ls and a few libraries in /lib.
> 
> I NEED to be able to compile apps from the sources.  I have managed to
> cross-compile ncurses and bash.  I can't get bash to run at all (even a
> statically compiled version).  I get segmentaion faults.  I'm currently
> using SASH which I have cross-compiled as a static binary.  I compiled a
> test app (bjs1.c) which outputs a string every second.  It is compiled
> as a static binary (bjs1-static) and a shared binary (bjs1-shared).  The
> static binary works but the shared one does not.  I assume it is some
> library problem but I can't figure out what.  The output of the sash
> session is below.
> 
> Stand-alone shell (version 1.0)
> > ./bjs1-static
> BJS1: Brendan was here
> BJS1: Brendan was here
> BJS1: Brendan was here
> pid 7: killed (signal 2)
> >
> > ./bjs1-shared
> pid 8: killed (signal 11)

 Some simple sanity checks for shared executables, before downloading them
into the target, follows...

1. Using 'strings' to see the 'hard-wired' name of the dynamic linker in
   the executable:

	E:\usr\local\samples>strings tst_ppc-linux.x | more
	/lib/ld.so.1	<------- !!!
	__gmon_start__
	libc.so.6
	strcpy
	printf
	stdout

2. Using 'objdump -p' to see the needed shared libs, version dependencies
   etc. :
-------------------- clip ---------------------
E:\usr\local\samples>objdump -p tst_ppc-linux.x

tst_ppc-linux-2.x:     file format elf32-powerpc

Program Header:
    PHDR off    0x0000000000000034 vaddr 0x0000000010000034 paddr 0x000000001000
0034 align 2**2
         filesz 0x00000000000000e0 memsz 0x00000000000000e0 flags r-x
  INTERP off    0x0000000000000114 vaddr 0x0000000010000114 paddr 0x000000001000
0114 align 2**0
         filesz 0x000000000000000d memsz 0x000000000000000d flags r--
    LOAD off    0x0000000000000000 vaddr 0x0000000010000000 paddr 0x000000001000
0000 align 2**16
         filesz 0x0000000000001860 memsz 0x0000000000001860 flags r-x
    LOAD off    0x0000000000001860 vaddr 0x0000000010011860 paddr 0x000000001001
1860 align 2**16
         filesz 0x000000000000012c memsz 0x00000000000001f0 flags rwx
 DYNAMIC off    0x00000000000018bc vaddr 0x00000000100118bc paddr 0x000000001001
18bc align 2**2
         filesz 0x00000000000000a8 memsz 0x00000000000000a8 flags rw-
    NOTE off    0x0000000000000130 vaddr 0x0000000010000130 paddr 0x000000001000
0130 align 2**4
         filesz 0x0000000000000020 memsz 0x0000000000000020 flags r--

Dynamic Section:
  NEEDED      libc.so.6
  NEEDED      ld.so.1
  INIT        0x100011f0
  FINI        0x10001214
  HASH        0x10000150
  STRTAB      0x1000027c
  SYMTAB      0x1000019c
  STRSZ       0xa4
  SYMENT      0x10
  DEBUG       0x0
  PLTGOT      0x10011990
  PLTRELSZ    0x78
  PLTREL      0x7
  JMPREL      0x10000368
  RELA        0x10000368
  RELASZ      0x84
  RELAENT     0xc
  VERNEED     0x10000348
  VERNEEDNUM  0x1
  VERSYM      0x1000032a

Version References:
  required from libc.so.6:
    0x0d696910 0x00 02 GLIBC_2.0

-------------------- clip ---------------------

 The previous executable probably searches the shared libs (libc.so.6 here) from the
default places, '/lib' and '/usr/lib' and the dynamic linker from the 'hard-wired'
place, given by '--dynamic-linker /lib/ld.so.1' in the GCC specs (LINK_SPEC).

 Using the '-rpath' one can add more directories to the run-time shared libs search
path, 'RPATH'.

  -rpath PATH                 Set runtime shared library search path
  -rpath-link PATH            Set link time shared library search path

 The '-rpath-link' (where to find the libs at link time) shouldn't be mixed with the
'-rpath' (where to find the libs at run time).

 Adding a '-Wl,-rpath,<something>' to the GCC compile&link command, the 'RPATH' row
will be added to the header of the previous executable :

-------------------- clip ---------------------
E:\usr\local\samples>gcc-ppc-linux -Wl,-rpath,/usr/mylib:/usr/yourlib -O -o tst_
ppc-linux-3.x tprintf.c

E:\usr\local\samples>objdump -p tst_ppc-linux-3.x

tst_ppc-linux-3.x:     file format elf32-powerpc

Program Header:
 <snip>

Dynamic Section:
  NEEDED      libc.so.6
  NEEDED      ld.so.1
  RPATH       /usr/mylib:/usr/yourlib
  INIT        0x10001208
  FINI        0x1000122c
 <snip>
-------------------- clip ---------------------

 Then the executable will search the shared libs also at '/usr/mylib' and
at '/usr/yourlib'...

> How does the kernel know where to look for libraries ?  I assume there
> are some default locations like /lib.  I haven't got an ld.so.conf setup
> nor do I have ldconfig.

 The previous simple tests, made in the cross-host, may help to reveal if
there is some basic fault or misunderstanding, e.g. the hard-wired dynamic-linker
name is now wrong in the executable.

 The 'ld.so.1' etc. components and their sanity can also be looked with the
'objdump -p' :

-------------------- clip ---------------------
E:\usr\local\ppc-linux-gnu\lib>objdump -p ld.so.1

ld.so.1:     file format elf32-powerpc

 <snip>

Dynamic Section:
  SONAME      ld.so.1
  HASH        0x94
  STRTAB      0x6e4
  SYMTAB      0x2b4
  STRSZ       0xcfa
  SYMENT      0x10
  PLTGOT      0x5661c
  PLTRELSZ    0x12c
  PLTREL      0x7
  JMPREL      0x292c
  RELA        0x1504
  RELASZ      0x1554
  RELAENT     0xc
  VERDEF      0x1484
  VERDEFNUM   0x4
  VERSYM      0x13fe

Version definitions:
1 0x01 0x0275a261 ld.so.1
2 0x00 0x0d696910 GLIBC_2.0
3 0x00 0x0d696911 GLIBC_2.1
        GLIBC_2.0
4 0x00 0x09691f71 GLIBC_2.1.1
        GLIBC_2.1

-------------------- clip ---------------------

 Don't ask me to interpret those version definitions, but I can guess that
if the one in the executable isn't listed in the 'ld.so.1', this means bad
troubles...

> It can't be that hard to get a simple 10 line program to execute as a
> shared binary.  It must be something really simple that I am missing.

 Perhaps the new 'readelf' utility in binutils can be used for sanity checks
of the same kind...

Cheers, Kai

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

Re: cross-compiling & debugging embedded-linux apps

[Kai Ruottu]

Brendan J Simon wrote:
> 
> Kai Ruottu wrote:
> 
> > 1. Using 'strings' to see the 'hard-wired' name of the dynamic linker in
> >    the executable:
> >
> >         E:\usr\local\samples>strings tst_ppc-linux.x | more
> >         /lib/ld.so.1    <------- !!!
> >         __gmon_start__
> >         libc.so.6
> 
> The output of "powerpc-linux-strings bjs1-shared" looks OK to me.
> $ powerpc-linux-strings bjs1-shared
> _DYNAMIC
> _GLOBAL_OFFSET_TABLE_
> __gmon_start__

 When your output from 'strings' didn't show the 'ld.so.1' (didn't it really?)
I tried removing the '--dynamic-linker xxxxx' from my specs, and got then :
 
	E:\usr\local\samples>strings tst_ppc-linux.x | more
	/usr/lib/ld.so.1    <------- !!!!
	__gmon_start__
	libc.so.6

 This could be the right place for 'ld.so.1' in a Linux/PPC-system and my
powerpc-linux executables have been this far just insane... (I should never guess
these things or trust my memory...)

> I'm not sure how to interpret the output of "powerpc-linux-objdump -p bjs1-shared".
> The output  is :
> $ powerpc-linux-objdump -p bjs1-shared
> <snip>
> Dynamic Section:
>   NEEDED      libc.so.6
>   INIT        0x610	<----- !!!!
>   FINI        0x634	<----- !!!!
>   HASH        0x94
>   STRTAB      0x310
>   SYMTAB      0x150
>   PLTGOT      0x40748
>   JMPREL      0x48c
>   RELA        0x420
>   VERNEED     0x400
>   VERSYM      0x3c8

 The addresses look to be too small, those from my 'ppc-linux-gnu' are all over
'0x10000000' :

	Dynamic Section:
	  NEEDED      libc.so.6
	  NEEDED      ld.so.1
	  INIT        0x100011f0
	  FINI        0x10001214
	  HASH        0x10000150
	  STRTAB      0x1000027c
	  SYMTAB      0x1000019c
	  PLTGOT      0x10011990
	  JMPREL      0x10000368
	  RELA        0x10000368
	  VERNEED     0x10000348
	  VERSYM      0x1000032a

which is the result of the default linker script (elf32ppclinux.x) :

	SECTIONS
	{
	  /* Read-only sections, merged into text segment: */
	  . = 0x10000000 + SIZEOF_HEADERS;
	  .interp   : { *(.interp) }
	  .hash           : { *(.hash)          }

 What should the base address be for a Linux/PPC executable?

> I don't see anything strange here.   I did the same for libc.so.6
> $ powerpc-linux-objdump -p lib/libc.so.6
> <snip>
> Version definitions:
> 1 0x01 0x0865f4e6 libc.so.6
> 2 0x00 0x0d696910 GLIBC_2.0
> 3 0x00 0x0d696911 GLIBC_2.1
>         GLIBC_2.0
> 
> Version References:
>   required from ld.so.1:
>     0x0d696911 0x00 05 GLIBC_2.1
>     0x0d696910 0x00 04 GLIBC_2.0
> 
> And again for ld.so.1
> $ powerpc-linux-objdump -p lib/ld.so.1
> <snip>
> Version definitions:
> 1 0x01 0x0275a261 ld.so.1
> 2 0x00 0x0d696910 GLIBC_2.0
> 3 0x00 0x0d696911 GLIBC_2.1
>         GLIBC_2.0
> 
> I don't see anything glaringly wrong but I don't exactly know what I would be looking
> for.  Can you see any problems ?

 Do you have just the same 'libc.so.6', 'ld.so.1' etc. in the cross-tools and in the
run-time environment?  Your executable seems to be linked using some glibc-2.1.x libs,
but do you have the same libs in the run-time target board?  Or just some smaller and
older ones ? (Recently someone somewhere wondered why the glibc-2.1.x libs are so big
when the older 2.0.6 ones were much smaller...).

 Better to use the older ones at least when linking...

 The generic rule is that one cannot run executables which were linked against newer
shared libs, using older shared libs at run-time.  No forwards-compatibility expected.
But all executables linked against older libs should run with newer shared libs. This
kind of backwards-compatability is always expected... At least between two releases. 

> >  Perhaps the new 'readelf' utility in binutils can be used for sanity checks
> > of the same kind...
> Never heard of it.  Is it part of binutils-2.9.1 or newer cvs and snapshots ?

 It is included with the new snapshots (perhaps almost a year now) :

E:\usr\local\ppc-linux-gnu\bin>readelf --version
GNU readelf 991116
Copyright 1997, 1998, 1999 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License.  This program has absolutely no warranty.

 And the 'elf32ppclinux' support appeared to them some time ago :

E:\usr\local\ppc-linux-gnu\bin>ld -V
GNU ld version 2.9.5 (with BFD 991116)
  Supported emulations:
   elf32ppclinux
   elf32ppc

 The difference between 'elf32ppc' and 'elf32ppclinux' was discussed some time ago,
but the only difference seems to be the base address, here is a clip from the default
linker script for elf32ppc :

	SECTIONS
	{
	  /* Read-only sections, merged into text segment: */
	  . = 0x01800000 + SIZEOF_HEADERS;
	  .interp   : { *(.interp) }
	  .hash           : { *(.hash)          }

 If the default linker script for 'elf32ppclinux' says in the same lines :

	SECTIONS
	{
	  /* Read-only sections, merged into text segment: */
	  . = 0x10000000 + SIZEOF_HEADERS;
	  .interp   : { *(.interp) }
	  .hash           : { *(.hash)          }

 So I'll repeat my question: "What should the base address to be for a Linux/PPC
executable?"

 Or doesn't it really matter if there is a '. = 0', '. = 0x01800000' or a '. = 0x10000000'
in the line after the comment?

 For all ELF/x86-systems the base address seems to be the same, but for MIPS, SPARC
etc. it seems to vary between different ELF-systems... The SVR4/PowerPC ABI Supplement
talks about '0x02000000' as the base address and the '/usr/lib/ld.so.1' is also the
'program interpreter' or the 'dynamic linker' there...

  BTW, is there something equivalent for Linux/PPC as there is for the never-seen
SVR4/PPC, the "System V Application Binary Interface, PowerPC Processor Supplement",
by Steve Zucker and Kari Karhi?  Sometimes it sounds very funny when there seems to
be no free docs for the "Free Linux" (only those "For Dummies" things), but quite a
lot for the commercial SVR4 (e.g. via 'www.sco.com/developer/devspecs').

 A document with the name "Linux Application Binary Interface,  PowerPC Processor
Supplement" seems to be still missing... For Linux/ARM, Linux/Alpha, Linux/MIPS,
Linux/M68K too... Isn't there any yet for Linux/x86? (Who said that MS tries to hide
the Windows ABI...). Some day all the money went to RedHat & Co. should be converted
into some docs... Meanwhile the SVR4-ABI docs, the ARM-ELF-ABI, DWARF etc. docs seem
to be the only for Linux. And the GNU sources of course, but who really likes to read
everything from the sources...

 Ok, if there were some nice PDF etc. docs for Linux/* ABIs, there could be much less
misunderstandings and much less trouble to find these 'base' things... But surely more
answers with the advice about 'RTFM'....

Cheers, Kai


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

Re: cross-compiling & debugging embedded-linux apps

[dony]

Kai Ruottu wrote:

> Brendan J Simon wrote:
> >
> > Kai Ruottu wrote:
> >
> > > 1. Using 'strings' to see the 'hard-wired' name of the dynamic linker in
> > >    the executable:
> > >
> > >         E:\usr\local\samples>strings tst_ppc-linux.x | more
> > >         /lib/ld.so.1    <------- !!!
> > >         __gmon_start__
> > >         libc.so.6
> >
> > The output of "powerpc-linux-strings bjs1-shared" looks OK to me.
> > $ powerpc-linux-strings bjs1-shared
> > _DYNAMIC
> > _GLOBAL_OFFSET_TABLE_
> > __gmon_start__
>
>  When your output from 'strings' didn't show the 'ld.so.1' (didn't it really?)
> I tried removing the '--dynamic-linker xxxxx' from my specs, and got then :

Now I have a similar problem with the dynamic linker "ld.so.1". Can you tell me
how can I remove the "--dynamic-linker XXXX" and set the default dynamic-linker to other
directories ,ie, /syslib/ld.so.1, instead of /lib/ld.so.1?

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