readelf/ldconfig confused about ELF header
Hamish Moffatt
hamish at cloud.net.au
Wed Oct 31 06:10:05 UTC 2007
I'm using buildroot to compile for armeb on a x86-64 (little-endian) host.
uclibc's readelf and ldconfig are giving confusing results reading the
headers of compiled libraries.
Programs run ok, but ldconfig decides that my target has mixed
byte-order libraries and generates a wrong-endianness ld.so.conf.
readelf says the right things for uClibc's own libraries:
[ 5:00PM] hamish at bach:europaboot/root/lib $ ../../../../build_armeb/staging_dir/usr/bin/armeb-linux-uclibcgnu-readelf -h libdl.so.0
ELF Header:
Magic: 7f 45 4c 46 01 02 01 61 00 00 00 00 00 00 00 00
Class: ELF32
Data: 2's complement, big endian
Version: 1 (current)
OS/ABI: ARM
ABI Version: 0
Type: DYN (Shared object file)
Machine: ARM
Version: 0x1
Entry point address: 0x788
Start of program headers: 52 (bytes into file)
Start of section headers: 8332 (bytes into file)
Flags: 0x202, has entry point, GNU EABI, software FP
Size of this header: 52 (bytes)
Size of program headers: 32 (bytes)
Number of program headers: 6
Size of section headers: 40 (bytes)
Number of section headers: 16
Section header string table index: 15
(although the GNU EABI part is not correct AFAICT). However for some reason for
the libraries built by ext2fsprogs,
[ 5:04PM] hamish at bach:europaboot/root/lib $ ../../../../build_armeb/staging_dir/usr/bin/armeb-linux-uclibcgnu-readelf -h libe2p.so
ELF Header:
Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00
Class: ELF64
Data: 2's complement, little endian
Version: 1 (current)
OS/ABI: UNIX - System V
ABI Version: 0
Type: DYN (Shared object file)
Machine: Advanced Micro Devices X86-64
Version: 0x1
Entry point address: 0x1db0
Start of program headers: 64 (bytes into file)
Start of section headers: 22704 (bytes into file)
Flags: 0x0
Size of this header: 64 (bytes)
Size of program headers: 56 (bytes)
Number of program headers: 5
Size of section headers: 64 (bytes)
Number of section headers: 25
Section header string table index: 24
However, objdump -p says the right things for this same library,
and I can run the programs linked to it ok.
[ 5:05PM] hamish at bach:europaboot/root/lib $ ../../../../build_armeb/staging_dir/usr/bin/armeb-linux-objdump -p libe2p.so.2.3
libe2p.so.2.3: file format elf32-bigarm
Program Header:
LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**15
filesz 0x00003afc memsz 0x00003afc flags r-x
LOAD off 0x00004000 vaddr 0x0000c000 paddr 0x0000c000 align 2**15
filesz 0x000003ac memsz 0x000005a4 flags rw-
DYNAMIC off 0x00004014 vaddr 0x0000c014 paddr 0x0000c014 align 2**2
filesz 0x000000d0 memsz 0x000000d0 flags rw-
Dynamic Section:
NEEDED libgcc_s.so.1
NEEDED libc.so.0
SONAME libe2p.so.2
INIT 0xef8
FINI 0x3044
HASH 0x94
STRTAB 0x7ac
SYMTAB 0x2dc
STRSZ 0x32f
SYMENT 0x10
PLTGOT 0xc0e4
PLTRELSZ 0x150
PLTREL 0x11
JMPREL 0xda8
REL 0xb98
RELSZ 0x210
RELENT 0x8
VERNEED 0xb78
VERNEEDNUM 0x1
VERSYM 0xadc
RELCOUNT 0x3b
Version References:
required from libgcc_s.so.1:
0x0b792650 0x00 02 GCC_3.0
private flags = 202: [APCS-32] [FPA float format] [software FP] [has entry point]
I guess this means something is whacky in ext2fsprog's library generation?
thanks
Hamish
--
Hamish Moffatt VK3SB <hamish at debian.org> <hamish at cloud.net.au>
More information about the uClibc
mailing list