My earlier understanding was incorrect. The problem (so far) is not in
the GOT. It is definitely in the relocation table.
After turning on verbose modes and enabling debug symbols in uClibc, etc
etc I was able to compare what elf2flt and the flat format loader were
doing. First, let's look at some dumps:
libc.elf
Sections:
Idx Name Size VMA LMA File off Algn
0 .text 00030be0 01000000 01000000 00002000 2**2
CONTENTS, ALLOC, LOAD, READONLY, CODE
1 .data 000040b0 01030be0 01030be0 00032be0 2**2
CONTENTS, ALLOC, LOAD, DATA
2 .bss 00002440 01034c90 01034c90 00036c90 2**2
ALLOC
Relocation section '.rela.data' at offset 0x1b3698 contains 293 entries:
Offset Info Type Sym.Value Sym. Name + Addend
00001e50 0007b301 R_68K_32 000010fc _string_syserrmsgs + 0
00001e54 0007b301 R_68K_32 000010fc _string_syserrmsgs + 8
00001e58 0007b301 R_68K_32 000010fc _string_syserrmsgs + 20
.
.
.
00002040 0007b301 R_68K_32 000010fc _string_syserrmsgs + b48
0000213e 00000301 R_68K_32 00000000 .data + 2f9f
GOT table contains 60 entries (480 bytes)
SECTION: .text [0x57a248]: flags=0x11b vma=0x1000000
SECTION: .data [0x57a358]: flags=0x123 vma=0x1030be0
RELOCS: .data [0x56c508]: flags=0x127 vma=0x1030be0
As far as I can tell, the elf2flt program calculates the reloc table in
the following way:
reloc_table[n] = .data vma + length of got + .rela.data Offset
The dereference of that calculated pointer = .data vma + length of got +
Sym.Value + Addend
So:
reloc_table[122]: 0x1032e00 (0x1030be0 + 480 + 0x2040) -> 0x1032a04
(0x1030be0 + 480 + 0x10fc + 0xb48)
This is the calculation for all _string_syserrmsgs values. Until
reaching (.data + 2f9f in the .rela.data table)
reloc_table[123]: 0x1032efe -> 0x1033b7c :: should be pointing to
0x1033D5F = 0x01030be0 + 480 + 0x2f9f
And as I've been seeing, the shared uClibc library croaks when it hits
its first non-zero incorrect entry pretending to be a reference to
library "0".
BINFMT_FLAT: Loading file: /lib/lib1.so
BINFMT_FLAT: ROM mapping of file (we hope)
BINFMT_FLAT: Allocated data+bss+stack (25840 bytes): ec8010
Mapping is e40000, Entry point is 44, data_start is 30c20
Lib /lib/lib1.so: TEXT=e40040-e70c20 DATA=ec8010-ecc0c0
BSS=ecc0c0-ece500
.
.
.
211: 0x1033588 -> rp=0xeca9b8, *rp=0x1034771 -> 0xecbba1 (relocation
success, but incorrect?)
212: 0x1034b5c -> rp=0xecbf8c, *rp=0x0 (not
relocated x 3)
213: 0x1034b60 -> rp=0xecbf90, *rp=0x0
214: 0x1034b64 -> rp=0xecbf94, *rp=0x0
215: 0x1034b68 -> rp=0xecbf98, *rp=0x1 BINFMT_FLAT: library 0 is younger
than 1, (dead!)
killing sh!
I feel like I'm driving with no map. Am I totally incorrect? Is this the
right list to be talking to?
Does anyone with experience (snapgear guys) have any recommendations?
- Jate S.
Original Message was:
________________________________
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jate Sujjavanich
Sent: Friday, July 20, 2007 6:02 PM
To: uClinux development list
Subject: [uClinux-dev] Shared library issues on m68knommu and gcc 4.1.1
I've discovered that the load of lib1.so (uClibc) fails when loaded for
/bin/init. The init process doesn't load properly. When the fixup
routine detects a need for shared library #1, the kernel proceeds to
load it. It loads uClibc including the Global Offset Table located right
after the .data section. It finishes offsetting the GOT pointers. Then
it offsets the destination pointers *GOT[1 - reloc_count].
Unfortunately, it hits a value '0x00000001' which is causing it to
perform the shared lib/main executable date check (lib 0x00 in the msb):
BINFMT_FLAT: library 0 is younger than 1, killing init!
This jives with the vague references to "toolchain issues" in past
discussion about this message. It seems that either the contents of the
GOT are incorrect, or the pointees of the GOT are incorrect. Or perhaps
the load is occuring incorrectly.
In order to determine this, I would need to make sense of exactly what
is being loaded. Does anyone know of good ways to generate information
about the symbols and contents of global offset tables? I have not yet
found the right combination of objdump options to do this.
- Jate S.
_______________________________________________
uClinux-dev mailing list
[email protected]
http://mailman.uclinux.org/mailman/listinfo/uclinux-dev
This message was resent by [email protected]
To unsubscribe see:
http://mailman.uclinux.org/mailman/options/uclinux-dev
