* Linux ABI documents and powerpc supplements.
@ 2000-01-04 23:00 Brendan J Simon
2000-01-05 0:23 ` Franz Sirl
0 siblings, 1 reply; 14+ messages in thread
From: Brendan J Simon @ 2000-01-04 23:00 UTC (permalink / raw)
To: linuxppc-dev
To linuxppc developers,
Kai Ruottu (who contributes a hell of a lot on the crossgcc mailing list and who
cross-compiles for many targets including i586-cygwin, i586-mingw, powerpc-linux,
powerpc-eabi, sparc-linux, arm-linux, etc) had some questions about Linux ABIs and powerpc
supplements. I have forwarded the entire email. Hopefully someone can point him to any
relevant docs and/or answer his questions. Most of his questions are towards the end of this
email.
Thanks,
Brendan Simon.
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 :
>
> 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'....
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: Linux ABI documents and powerpc supplements.
2000-01-04 23:00 Linux ABI documents and powerpc supplements Brendan J Simon
@ 2000-01-05 0:23 ` Franz Sirl
2000-01-05 5:08 ` Brendan J Simon
0 siblings, 1 reply; 14+ messages in thread
From: Franz Sirl @ 2000-01-05 0:23 UTC (permalink / raw)
To: Brendan J Simon, linuxppc-dev
0x10000000 + SIZEOF_HEADERS is the current recommended base address for
Linux/PPC. It was changed sometime ago from 0x1800000 to better support running
the binaries on AIX. On Linux we use /lib/ld.so.1, Linux overrules the SYSV ABI
here. The size of the libraries if you are talking about the standard Linux/PPC
ones is due to a bug in 'strip' which tends to corrupt the libraries.
The most current documentation I know of is in
<ftp://sourceware.cygnus.com/pub/binutils/ppc-docs/>
Franz.
Am Wed, 05 Jan 2000 schrieb Brendan J Simon:
>To linuxppc developers,
>
>Kai Ruottu (who contributes a hell of a lot on the crossgcc mailing list and who
>cross-compiles for many targets including i586-cygwin, i586-mingw, powerpc-linux,
>powerpc-eabi, sparc-linux, arm-linux, etc) had some questions about Linux ABIs and powerpc
>supplements. I have forwarded the entire email. Hopefully someone can point him to any
>relevant docs and/or answer his questions. Most of his questions are towards the end of this
>email.
>
>Thanks,
>Brendan Simon.
>
>
>
>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 :
>>
>> 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'....
>
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: Linux ABI documents and powerpc supplements.
2000-01-05 0:23 ` Franz Sirl
@ 2000-01-05 5:08 ` Brendan J Simon
2000-01-05 6:46 ` Momchil 'Velco' Velikov
0 siblings, 1 reply; 14+ messages in thread
From: Brendan J Simon @ 2000-01-05 5:08 UTC (permalink / raw)
To: Franz Sirl; +Cc: linuxppc-dev
Franz Sirl wrote:
> 0x10000000 + SIZEOF_HEADERS is the current recommended base address for
> Linux/PPC. It was changed sometime ago from 0x1800000 to better support running
> the binaries on AIX. On Linux we use /lib/ld.so.1, Linux overrules the SYSV ABI
> here. The size of the libraries if you are talking about the standard Linux/PPC
> ones is due to a bug in 'strip' which tends to corrupt the libraries.
>
> The most current documentation I know of is in
> <ftp://sourceware.cygnus.com/pub/binutils/ppc-docs/>
Thanks. I just downloaded the "System V Application Binary Interface PowerPC Processor
Supplement". It is dated September 1995 and is authored by Steve Zucker (SunSoft) and Kari Karhi
(IBM). Chapter 3 (page 3-24) says that "a program base of 0x02000000 (32 MB) is recommended for
reasons given in chapter 5". I take it that the Linux/PPC supplement would state that a base of
0x10000000+SIZEOF_HEADERS is recommneded. Is there such a beast as a Linux/PPC supplement ?
I am having problems getting simple shared executalbes to work on my embedded powerpc system
(MPC860). I am using an egcs-1.1.2 cross compiler and have cross-compiled linux-2.2.5 kernel,
glibc-2.1 and some simple test applications. I have an app that outputs a string every second
using puts(). If I compile with "powerpc-linux-gcc -m860 -static" it works, but if I compile
with "powerpc-linux-gcc -m860 -shared" it doesn't work. I am mount root via nfs and the nfs
daemon is in debug mode. I can see the libraries being accessed and read but the app just
segfaults. Here is the "powerpc-linux-objdump -p" of the test apps and the libraries. Do they
look OK ?
Would the segfault occur when loading the shared libraries into memory or when trying to execute
code from memory ?
Do I need -fPIC or does -shared impy this ?
Thanks,
Brendan Simon.
bjs1-static: file format elf32-powerpc
Program Header:
LOAD off 0x00000000 vaddr 0x01800000 paddr 0x01800000 align 2**16
filesz 0x00038910 memsz 0x00038910 flags r-x
LOAD off 0x00038910 vaddr 0x01878910 paddr 0x01878910 align 2**16
filesz 0x000015ac memsz 0x00002034 flags rw-
NOTE off 0x000000a0 vaddr 0x018000a0 paddr 0x018000a0 align 2**4
filesz 0x00000020 memsz 0x00000020 flags r--
bjs1-shared: file format elf32-powerpc
Program Header:
LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**16
filesz 0x0000066c memsz 0x0000066c flags r-x
LOAD off 0x00000670 vaddr 0x00040670 paddr 0x00040670 align 2**16
filesz 0x000000d8 memsz 0x0000015c flags rwx
DYNAMIC off 0x00000678 vaddr 0x00040678 paddr 0x00040678 align 2**2
filesz 0x000000a0 memsz 0x000000a0 flags rw-
Dynamic Section:
NEEDED libc.so.6
INIT 0x610
FINI 0x634
HASH 0x94
STRTAB 0x310
SYMTAB 0x150
STRSZ 0xad
SYMENT 0x10
PLTGOT 0x40748
PLTRELSZ 0x3c
PLTREL 0x7
JMPREL 0x48c
RELA 0x420
RELASZ 0xa8
RELAENT 0xc
TEXTREL 0x0
VERNEED 0x400
VERNEEDNUM 0x1
VERSYM 0x3c8
Version References:
required from libc.so.6:
0x0d696910 0x00 02 GLIBC_2.0
lib/libc.so.6: file format elf32-powerpc
Program Header:
PHDR off 0x00000034 vaddr 0x00000034 paddr 0x00000034 align 2**2
filesz 0x000000c0 memsz 0x000000c0 flags r-x
INTERP off 0x000e8760 vaddr 0x00128760 paddr 0x00128760 align 2**2
filesz 0x00000010 memsz 0x00000010 flags rw-
LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**16
filesz 0x000d9f1c memsz 0x000d9f1c flags r-x
LOAD off 0x000d9f20 vaddr 0x00119f20 paddr 0x00119f20 align 2**16
filesz 0x00012fa0 memsz 0x00016a48 flags rwx
DYNAMIC off 0x000e8a30 vaddr 0x00128a30 paddr 0x00128a30 align 2**2
filesz 0x000000b0 memsz 0x000000b0 flags rw-
Dynamic Section:
NEEDED ld.so.1
SONAME libc.so.6
INIT 0x21738
FINI 0xd9eb0
HASH 0xf4
STRTAB 0x9728
SYMTAB 0x2be8
STRSZ 0x79ba
SYMENT 0x10
PLTGOT 0x12cec0
PLTRELSZ 0x14d0
PLTREL 0x7
JMPREL 0x1ff50
RELA 0x11eec
RELASZ 0xf714
RELAENT 0xc
VERDEF 0x11e60
VERDEFNUM 0x3
VERNEED 0x11ebc
VERNEEDNUM 0x1
VERSYM 0x110f6
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
lib/ld.so.1: file format elf32-powerpc
Program Header:
LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**16
filesz 0x00013fb8 memsz 0x00013fb8 flags r-x
LOAD off 0x00013fc0 vaddr 0x00053fc0 paddr 0x00053fc0 align 2**16
filesz 0x00002bc8 memsz 0x000032c0 flags rwx
DYNAMIC off 0x00016378 vaddr 0x00056378 paddr 0x00056378 align 2**2
filesz 0x00000088 memsz 0x00000088 flags rw-
Dynamic Section:
SONAME ld.so.1
HASH 0x94
STRTAB 0xf28
SYMTAB 0x528
STRSZ 0xcc4
SYMENT 0x10
PLTGOT 0x56c2c
PLTRELSZ 0x330
PLTREL 0x7
JMPREL 0x3170
RELA 0x1d9c
RELASZ 0x1704
RELAENT 0xc
VERDEF 0x1d40
VERDEFNUM 0x3
VERSYM 0x1c00
Version definitions:
1 0x01 0x0275a261 ld.so.1
2 0x00 0x0d696910 GLIBC_2.0
3 0x00 0x0d696911 GLIBC_2.1
GLIBC_2.0
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: Linux ABI documents and powerpc supplements.
2000-01-05 5:08 ` Brendan J Simon
@ 2000-01-05 6:46 ` Momchil 'Velco' Velikov
2000-01-05 6:21 ` Brendan J Simon
2000-01-05 7:04 ` dynamic binaries not working Brendan J Simon
0 siblings, 2 replies; 14+ messages in thread
From: Momchil 'Velco' Velikov @ 2000-01-05 6:46 UTC (permalink / raw)
To: Brendan.Simon; +Cc: Franz Sirl, linuxppc-dev
Brendan J Simon wrote:
> I am having problems getting simple shared executalbes to work on my embedded powerpc system
> (MPC860). I am using an egcs-1.1.2 cross compiler and have cross-compiled linux-2.2.5 kernel,
> glibc-2.1 and some simple test applications. I have an app that outputs a string every second
> using puts(). If I compile with "powerpc-linux-gcc -m860 -static" it works, but if I compile
> with "powerpc-linux-gcc -m860 -shared" it doesn't work. I am mount root via nfs and the nfs
-shared is used to *create* a shared library. You need -Bdynamic in
order to force the executable to be linked against shared libraries.
Regards,
-velco
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: Linux ABI documents and powerpc supplements.
2000-01-05 6:46 ` Momchil 'Velco' Velikov
@ 2000-01-05 6:21 ` Brendan J Simon
2000-01-05 10:19 ` Michael Schmitz
2000-01-05 7:04 ` dynamic binaries not working Brendan J Simon
1 sibling, 1 reply; 14+ messages in thread
From: Brendan J Simon @ 2000-01-05 6:21 UTC (permalink / raw)
To: Momchil 'Velco' Velikov; +Cc: linuxppc-dev
Momchil 'Velco' Velikov wrote:
> Brendan J Simon wrote:
> > I am having problems getting simple shared executalbes to work on my embedded powerpc system
> > (MPC860). I am using an egcs-1.1.2 cross compiler and have cross-compiled linux-2.2.5 kernel,
> > glibc-2.1 and some simple test applications. I have an app that outputs a string every second
> > using puts(). If I compile with "powerpc-linux-gcc -m860 -static" it works, but if I compile
> > with "powerpc-linux-gcc -m860 -shared" it doesn't work. I am mount root via nfs and the nfs
>
> -shared is used to *create* a shared library. You need -Bdynamic in
> order to force the executable to be linked against shared libraries.
I think you are confusing the ld arguments and the gcc arguments. ld uses -Bdynamic and -Bstatic
for force linking of dynamic or static executables. If -shared is specified on the gcc command
line then, it is passed to ld as -Bdynamic. If -static is specified on the gcc command line, then
it is passed to ld as -Bstatic. That's my understanding of it. I've just noticed that ld has a
-shared argument also which is used for creating shared libraries as you have stated. If -shared
on the gcc command line is passed unmodified to ld, then a shared library will be created instead
of an execuable. I guess I can check using -v. I should probably just leave the -shared option
out.
Thanks for your help,
Brendan Simon.
The gcc info pages say :
`-static'
On systems that support dynamic linking, this prevents linking
with the shared libraries. On other systems, this option has no
effect.
`-shared'
Produce a shared object which can then be linked with other
objects to form an executable. Not all systems support this
option. You must also specify `-fpic' or `-fPIC' on some systems
when you specify this option.
`-BPREFIX'
This option specifies where to find the executables, libraries,
include files, and data files of the compiler itself.
The compiler driver program runs one or more of the subprograms
`cpp', `cc1', `as' and `ld'. It tries PREFIX as a prefix for each
program it tries to run, both with and without `MACHINE/VERSION/'
(*note Target Options::.).
For each subprogram to be run, the compiler driver first tries the
`-B' prefix, if any. If that name is not found, or if `-B' was
not specified, the driver tries two standard prefixes, which are
`/usr/lib/gcc/' and `/usr/local/lib/gcc-lib/'. If neither of
those results in a file name that is found, the unmodified program
name is searched for using the directories specified in your
`PATH' environment variable.
`-B' prefixes that effectively specify directory names also apply
to libraries in the linker, because the compiler translates these
options into `-L' options for the linker. They also apply to
includes files in the preprocessor, because the compiler
translates these options into `-isystem' options for the
preprocessor. In this case, the compiler appends `include' to the
prefix.
The run-time support file `libgcc.a' can also be searched for using
the `-B' prefix, if needed. If it is not found there, the two
standard prefixes above are tried, and that is all. The file is
left out of the link if it is not found by those means.
Another way to specify a prefix much like the `-B' prefix is to use
the environment variable `GCC_EXEC_PREFIX'. *Note Environment
Variables::.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: Linux ABI documents and powerpc supplements.
2000-01-05 6:21 ` Brendan J Simon
@ 2000-01-05 10:19 ` Michael Schmitz
0 siblings, 0 replies; 14+ messages in thread
From: Michael Schmitz @ 2000-01-05 10:19 UTC (permalink / raw)
To: Brendan J Simon; +Cc: Momchil 'Velco' Velikov, linuxppc-dev
> > -shared is used to *create* a shared library. You need -Bdynamic in
> > order to force the executable to be linked against shared libraries.
>
> I think you are confusing the ld arguments and the gcc arguments. ld uses -Bdynamic and -Bstatic
I think you misread the documentation. It has always been my understanding
that -static explicitly prevents linking to shared libraries (which is
otherwise the default), wheras -shared prepares an object to be used as
part of a shared library later:
> `-shared'
> Produce a shared object which can then be linked with other
> objects to form an executable. Not all systems support this
> option. You must also specify `-fpic' or `-fPIC' on some systems
> when you specify this option.
That pretty much states it makes no sense using -shared in the final
linkage step for a binary.
Michael
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 14+ messages in thread
* dynamic binaries not working.
2000-01-05 6:46 ` Momchil 'Velco' Velikov
2000-01-05 6:21 ` Brendan J Simon
@ 2000-01-05 7:04 ` Brendan J Simon
2000-01-05 8:34 ` Daniel Jacobowitz
2000-01-05 12:47 ` Kenneth Johansson
1 sibling, 2 replies; 14+ messages in thread
From: Brendan J Simon @ 2000-01-05 7:04 UTC (permalink / raw)
Cc: linuxppc-dev
Momchil 'Velco' Velikov wrote:
> Brendan J Simon wrote:
> > I am having problems getting simple shared executalbes to work on my embedded powerpc system
> > (MPC860). I am using an egcs-1.1.2 cross compiler and have cross-compiled linux-2.2.5 kernel,
> > glibc-2.1 and some simple test applications. I have an app that outputs a string every second
> > using puts(). If I compile with "powerpc-linux-gcc -m860 -static" it works, but if I compile
> > with "powerpc-linux-gcc -m860 -shared" it doesn't work. I am mount root via nfs and the nfs
>
> -shared is used to *create* a shared library. You need -Bdynamic in
> order to force the executable to be linked against shared libraries.
I removed the -shared argument and the executable now looks a lot better interms of the vaddr and
program headers etc. I used "powerpc-linux-gcc -Wall -mcpu=860 -fpic -o bjs1 bjs1.c". I tried
with -fPIC, -fpic and without either. The program still does not run however. The output of
objdump -p is below.
Does this look OK ?
Any suggestions for debugging the code or the shared libraries ?
Thanks,
Brendan Simon.
# powerpc-linux-objdump -p bjs1
bjs1: file format elf32-powerpc
Program Header:
PHDR off 0x00000034 vaddr 0x01800034 paddr 0x01800034 align 2**2
filesz 0x000000e0 memsz 0x000000e0 flags r-x
INTERP off 0x00000114 vaddr 0x01800114 paddr 0x01800114 align 2**0
filesz 0x0000000d memsz 0x0000000d flags r--
LOAD off 0x00000000 vaddr 0x01800000 paddr 0x01800000 align 2**16
filesz 0x000004e4 memsz 0x000004e4 flags r-x
LOAD off 0x000004e8 vaddr 0x018404e8 paddr 0x018404e8 align 2**16
filesz 0x000000e4 memsz 0x00000168 flags rwx
DYNAMIC off 0x00000508 vaddr 0x01840508 paddr 0x01840508 align 2**2
filesz 0x000000a0 memsz 0x000000a0 flags rw-
NOTE off 0x00000130 vaddr 0x01800130 paddr 0x01800130 align 2**4
filesz 0x00000020 memsz 0x00000020 flags r--
Dynamic Section:
NEEDED libc.so.6
INIT 0x180048c
FINI 0x18004b0
HASH 0x1800150
STRTAB 0x1800204
SYMTAB 0x1800184
STRSZ 0x74
SYMENT 0x10
DEBUG 0x0
PLTGOT 0x18405cc
PLTRELSZ 0x3c
PLTREL 0x7
JMPREL 0x18002b4
RELA 0x18002b4
RELASZ 0x3c
RELAENT 0xc
VERNEED 0x1800294
VERNEEDNUM 0x1
VERSYM 0x1800282
Version References:
required from libc.so.6:
0x0d696910 0x00 02 GLIBC_2.0
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: dynamic binaries not working.
2000-01-05 7:04 ` dynamic binaries not working Brendan J Simon
@ 2000-01-05 8:34 ` Daniel Jacobowitz
2000-01-05 12:47 ` Kenneth Johansson
1 sibling, 0 replies; 14+ messages in thread
From: Daniel Jacobowitz @ 2000-01-05 8:34 UTC (permalink / raw)
To: Brendan J Simon; +Cc: linuxppc-dev
On Wed, Jan 05, 2000 at 06:04:14PM +1100, Brendan J Simon wrote:
>
> Momchil 'Velco' Velikov wrote:
>
> > Brendan J Simon wrote:
> > > I am having problems getting simple shared executalbes to work on my embedded powerpc system
> > > (MPC860). I am using an egcs-1.1.2 cross compiler and have cross-compiled linux-2.2.5 kernel,
> > > glibc-2.1 and some simple test applications. I have an app that outputs a string every second
> > > using puts(). If I compile with "powerpc-linux-gcc -m860 -static" it works, but if I compile
> > > with "powerpc-linux-gcc -m860 -shared" it doesn't work. I am mount root via nfs and the nfs
> >
> > -shared is used to *create* a shared library. You need -Bdynamic in
> > order to force the executable to be linked against shared libraries.
>
> I removed the -shared argument and the executable now looks a lot better interms of the vaddr and
> program headers etc. I used "powerpc-linux-gcc -Wall -mcpu=860 -fpic -o bjs1 bjs1.c". I tried
> with -fPIC, -fpic and without either. The program still does not run however. The output of
> objdump -p is below.
You should not need -fpic in any form for the binary.
Also, you're using old versions of tools - I really strongly recommend
upgrading. GCC 2.95.2 is worlds better than egcs 1.1.2 was, and the
new binutils (2.9.5.0.x) fix many nasty little bugs.
Nothing below looked wrong to my inexperienced eye...
Dan
/--------------------------------\ /--------------------------------\
| Daniel Jacobowitz |__| SCS Class of 2002 |
| Debian GNU/Linux Developer __ Carnegie Mellon University |
| dan@debian.org | | dmj+@andrew.cmu.edu |
\--------------------------------/ \--------------------------------/
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: dynamic binaries not working.
2000-01-05 7:04 ` dynamic binaries not working Brendan J Simon
2000-01-05 8:34 ` Daniel Jacobowitz
@ 2000-01-05 12:47 ` Kenneth Johansson
2000-01-05 22:24 ` MPC860 patches for glibc Brendan J Simon
1 sibling, 1 reply; 14+ messages in thread
From: Kenneth Johansson @ 2000-01-05 12:47 UTC (permalink / raw)
To: Brendan.Simon; +Cc: linuxppc-dev
Brendan J Simon wrote:
> Momchil 'Velco' Velikov wrote:
>
>
> I removed the -shared argument and the executable now looks a lot better interms of the vaddr and
> program headers etc. I used "powerpc-linux-gcc -Wall -mcpu=860 -fpic -o bjs1 bjs1.c". I tried
> with -fPIC, -fpic and without either. The program still does not run however. The output of
> objdump -p is below.
> Does this look OK ?
> Any suggestions for debugging the code or the shared libraries ?
>
Have you patched your glibc source so it can work on 860 ??
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 14+ messages in thread
* MPC860 patches for glibc
2000-01-05 12:47 ` Kenneth Johansson
@ 2000-01-05 22:24 ` Brendan J Simon
2000-01-05 23:36 ` Graham Stoney
0 siblings, 1 reply; 14+ messages in thread
From: Brendan J Simon @ 2000-01-05 22:24 UTC (permalink / raw)
To: linuxppc-dev, linuxppc-embedded
Kenneth Johansson wrote:
> Brendan J Simon wrote:
>
> > Momchil 'Velco' Velikov wrote:
> >
> >
> > I removed the -shared argument and the executable now looks a lot better interms of the vaddr and
> > program headers etc. I used "powerpc-linux-gcc -Wall -mcpu=860 -fpic -o bjs1 bjs1.c". I tried
> > with -fPIC, -fpic and without either. The program still does not run however. The output of
> > objdump -p is below.
> > Does this look OK ?
> > Any suggestions for debugging the code or the shared libraries ?
> >
>
> Have you patched your glibc source so it can work on 860 ??
I didn't realise there were 860 patches for glibc.
Where can I get these patches from ?
What do they do ?
I just ran configure and make with CC="powerpc-linux-gcc -mcpu=860" or CFLAGS=-mcpu=860. I can't
remember which.
Thanks,
Brendan Simon.
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: MPC860 patches for glibc
2000-01-05 22:24 ` MPC860 patches for glibc Brendan J Simon
@ 2000-01-05 23:36 ` Graham Stoney
2000-01-06 13:18 ` Jesper Skov
0 siblings, 1 reply; 14+ messages in thread
From: Graham Stoney @ 2000-01-05 23:36 UTC (permalink / raw)
To: Brendan.Simon; +Cc: linuxppc-dev, linuxppc-embedded
Brendan J Simon writes:
> I didn't realise there were 860 patches for glibc.
> Where can I get these patches from ?
The magic mailing list archive, of course (-:
http://lists.linuxppc.org/listarcs/linuxppc-embedded/199909/msg00000.html
> What do they do ?
Fix the cache line size for dynamic loading, and rearrange the FPU stuff so
it doesn't get included when you build.
Regards,
Graham
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 14+ messages in thread
* Re: MPC860 patches for glibc
2000-01-05 23:36 ` Graham Stoney
@ 2000-01-06 13:18 ` Jesper Skov
2000-01-07 1:44 ` Brendan J Simon
0 siblings, 1 reply; 14+ messages in thread
From: Jesper Skov @ 2000-01-06 13:18 UTC (permalink / raw)
To: Graham Stoney; +Cc: Brendan.Simon, linuxppc-dev, linuxppc-embedded, dmalek
>>>>> "Graham" == Graham Stoney <greyham@research.canon.com.au> writes:
Graham> Brendan J Simon writes:
>> I didn't realise there were 860 patches for glibc. Where can I get
>> these patches from ?
Graham> The magic mailing list archive, of course (-:
Graham> http://lists.linuxppc.org/listarcs/linuxppc-embedded/199909/msg00000.html
>> What do they do ?
Graham> Fix the cache line size for dynamic loading, and rearrange the
Graham> FPU stuff so it doesn't get included when you build.
I think the below patch for dl-machine.c would be better. It incurs no
loop overhead on the 32-byte cache line CPUs - and I think the double
flush of the same line should be harmless (and cheaper than the loop
overhead).
There is one small potential for error; if the macro is called with a
(32-byte aligned pointer)+16/17/18...31 in which case the first 16
bytes (of the 32-byte aligned address) would not be flushed on a 8xx,
while they would be on a bigger CPU. (did that make any sense at all ;)
Comments? Is it as safe/sensible as I think it is?
Thanks,
Jesper
--- powerpc/dl-machine.c~ Fri Mar 5 00:26:43 1999
+++ powerpc/dl-machine.c Thu Jan 6 14:09:34 2000
@@ -63,10 +63,17 @@
#define OPCODE_SLWI(ra,rs,sh) OPCODE_RLWINM(ra,rs,sh,0,31-sh)
-#define PPC_DCBST(where) asm ("dcbst 0,%0" : : "r"(where) : "memory")
+/* The macros dealing with cache lines affect both (where) and
+ (where+16). This is in order to support the 8xx CPUs which have
+ 16-byte cache lines. On the CPUs with 32-byte cache lines this
+ should have no noticable effect as the first store instruction
+ would effectively make the second instruction a NOP (since the line
+ would no longer be dirty). */
+#define PPC_DCBST(where) asm ("dcbst 0,%0;dcbst 0,%1" : : "r"(where), "r"((unsigned long)(where)+16) : "memory")
+#define PPC_ICBI(where) asm ("icbi 0,%0;icbi 0,%1" : : "r"(where), "r"((unsigned long)(where)+16) : "memory")
+
#define PPC_SYNC asm ("sync" : : : "memory")
#define PPC_ISYNC asm volatile ("sync; isync" : : : "memory")
-#define PPC_ICBI(where) asm ("icbi 0,%0" : : "r"(where) : "memory")
#define PPC_DIE asm volatile ("tweq 0,0")
/* Use this when you've modified some code, but it won't be in the
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: MPC860 patches for glibc
2000-01-06 13:18 ` Jesper Skov
@ 2000-01-07 1:44 ` Brendan J Simon
2000-01-08 8:46 ` Jesper Skov
0 siblings, 1 reply; 14+ messages in thread
From: Brendan J Simon @ 2000-01-07 1:44 UTC (permalink / raw)
Cc: linuxppc-dev, linuxppc-embedded, glibc-linux
Would the changes suggested below, to the cache line size (mpc8xx = 16 bytes, others = 32 bytes) make any difference
if my Instruction Cache and Data Cache was disabled. My current linux kernel has them all disabled for now.
Brendan Simon.
Jesper Skov wrote:
> >>>>> "Graham" == Graham Stoney <greyham@research.canon.com.au> writes:
>
> Graham> Brendan J Simon writes:
> >> I didn't realise there were 860 patches for glibc. Where can I get
> >> these patches from ?
>
> Graham> The magic mailing list archive, of course (-:
>
> Graham> http://lists.linuxppc.org/listarcs/linuxppc-embedded/199909/msg00000.html
>
> >> What do they do ?
>
> Graham> Fix the cache line size for dynamic loading, and rearrange the
> Graham> FPU stuff so it doesn't get included when you build.
>
> I think the below patch for dl-machine.c would be better. It incurs no
> loop overhead on the 32-byte cache line CPUs - and I think the double
> flush of the same line should be harmless (and cheaper than the loop
> overhead).
>
> There is one small potential for error; if the macro is called with a
> (32-byte aligned pointer)+16/17/18...31 in which case the first 16
> bytes (of the 32-byte aligned address) would not be flushed on a 8xx,
> while they would be on a bigger CPU. (did that make any sense at all ;)
>
> Comments? Is it as safe/sensible as I think it is?
>
> Thanks,
> Jesper
>
> --- powerpc/dl-machine.c~ Fri Mar 5 00:26:43 1999
> +++ powerpc/dl-machine.c Thu Jan 6 14:09:34 2000
> @@ -63,10 +63,17 @@
> #define OPCODE_SLWI(ra,rs,sh) OPCODE_RLWINM(ra,rs,sh,0,31-sh)
>
>
> -#define PPC_DCBST(where) asm ("dcbst 0,%0" : : "r"(where) : "memory")
> +/* The macros dealing with cache lines affect both (where) and
> + (where+16). This is in order to support the 8xx CPUs which have
> + 16-byte cache lines. On the CPUs with 32-byte cache lines this
> + should have no noticable effect as the first store instruction
> + would effectively make the second instruction a NOP (since the line
> + would no longer be dirty). */
> +#define PPC_DCBST(where) asm ("dcbst 0,%0;dcbst 0,%1" : : "r"(where), "r"((unsigned long)(where)+16) : "memory")
> +#define PPC_ICBI(where) asm ("icbi 0,%0;icbi 0,%1" : : "r"(where), "r"((unsigned long)(where)+16) : "memory")
> +
> #define PPC_SYNC asm ("sync" : : : "memory")
> #define PPC_ISYNC asm volatile ("sync; isync" : : : "memory")
> -#define PPC_ICBI(where) asm ("icbi 0,%0" : : "r"(where) : "memory")
> #define PPC_DIE asm volatile ("tweq 0,0")
>
> /* Use this when you've modified some code, but it won't be in the
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 14+ messages in thread* Re: MPC860 patches for glibc
2000-01-07 1:44 ` Brendan J Simon
@ 2000-01-08 8:46 ` Jesper Skov
0 siblings, 0 replies; 14+ messages in thread
From: Jesper Skov @ 2000-01-08 8:46 UTC (permalink / raw)
To: Brendan.Simon; +Cc: linuxppc-dev, linuxppc-embedded, glibc-linux
>>>>> "Brendan" == Brendan J Simon <Brendan.Simon@ctam.com.au> writes:
Brendan> Would the changes suggested below, to the cache line size
Brendan> (mpc8xx = 16 bytes, others = 32 bytes) make any difference if
Brendan> my Instruction Cache and Data Cache was disabled. My current
Brendan> linux kernel has them all disabled for now.
I can't imagine so. But you may want someone with more experience to
answer your question :)
Jesper
** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2000-01-08 8:46 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2000-01-04 23:00 Linux ABI documents and powerpc supplements Brendan J Simon
2000-01-05 0:23 ` Franz Sirl
2000-01-05 5:08 ` Brendan J Simon
2000-01-05 6:46 ` Momchil 'Velco' Velikov
2000-01-05 6:21 ` Brendan J Simon
2000-01-05 10:19 ` Michael Schmitz
2000-01-05 7:04 ` dynamic binaries not working Brendan J Simon
2000-01-05 8:34 ` Daniel Jacobowitz
2000-01-05 12:47 ` Kenneth Johansson
2000-01-05 22:24 ` MPC860 patches for glibc Brendan J Simon
2000-01-05 23:36 ` Graham Stoney
2000-01-06 13:18 ` Jesper Skov
2000-01-07 1:44 ` Brendan J Simon
2000-01-08 8:46 ` Jesper Skov
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).