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/
