On Sun, Feb 06, 2005 at 10:36:06AM -0700, Joel Aelwyn wrote:
> Since it's been a while...
>
> 1) Things can be found at http://nienna.lightbearer.com/
Correction: http://nienna.lightbearer.com:8088/
Sorry about that, stupid mistake on my part.
> 4) I appear to be close-to-done with the 2.0 tree netbsd-libc package.
This appears to be done and working, modulo one very strange issue that I'm
hoping someone on this list is enough of a NetBSD guru to help me sort out.
*) The ld.elf_so compiled from the 1.6 sources works fine (or at least,
as expected; it segfaults after an assertion about pAUX), and looks
reasonable under objdump -x.
*) The ld.elf_so compiled from the 2.0 sources on a native NetBSD system
runs fine, looks sane under objdump -x.
*) The ld.elf_so compiled by running do-ld.so, with DESTDIR, MACHINE, and
MACHINE_ARCH all set, and with do-lib-csu, do-lib-libc, and do-lib all
having been run first (aimed at the DESTDIR), but not do-build (that
comes after do-ld.so), builds a binary without errors, but the binary
looks really odd, and segfaults any time you try to directly invoke it.
The objdump -x for a native 2.0 ld.elf_so looks like:
/lib/ld.elf_so: file format elf32-i386
/lib/ld.elf_so
architecture: i386, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x000019b0
Program Header:
LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**12
filesz 0x00008904 memsz 0x00008904 flags r-x
LOAD off 0x00009000 vaddr 0x00009000 paddr 0x00009000 align 2**12
filesz 0x0000042c memsz 0x00000988 flags rw-
DYNAMIC off 0x00009320 vaddr 0x00009320 paddr 0x00009320 align 2**2
filesz 0x00000078 memsz 0x00000078 flags rw-
NOTE off 0x000088ec vaddr 0x000088ec paddr 0x000088ec align 2**2
filesz 0x00000018 memsz 0x00000018 flags r--
Dynamic Section:
SYMBOLIC 0x0
HASH 0xb4
STRTAB 0xf34
SYMTAB 0x544
STRSZ 0x5b3
SYMENT 0x10
REL 0x14e8
RELSZ 0x4c8
RELENT 0x8
RELCOUNT 0x99
While the one that's having problems looks like:
/lib/ld.elf_so.distrib: file format elf32-i386
/lib/ld.elf_so.distrib
architecture: i386, flags 0x00000150:
HAS_SYMS, DYNAMIC, D_PAGED
start address 0x00002fa4
Program Header:
LOAD off 0x00000000 vaddr 0x00000000 paddr 0x00000000 align 2**12
filesz 0x0000a5e4 memsz 0x0000a5e4 flags r-x
LOAD off 0x0000a600 vaddr 0x0000b600 paddr 0x0000b600 align 2**12
filesz 0x00000e30 memsz 0x00001844 flags rw-
DYNAMIC off 0x0000b184 vaddr 0x0000c184 paddr 0x0000c184 align 2**2
filesz 0x00000098 memsz 0x00000098 flags rw-
NOTE off 0x0000a5cc vaddr 0x0000a5cc paddr 0x0000a5cc align 2**2
filesz 0x00000018 memsz 0x00000018 flags r--
Dynamic Section:
HASH 0xb4
STRTAB 0x15c8
SYMTAB 0x768
STRSZ 0xb11
SYMENT 0x10
PLTGOT 0xc21c
PLTRELSZ 0x2e8
PLTREL 0x11
JMPREL 0x26dc
REL 0x20dc
RELSZ 0x600
RELENT 0x8
TEXTREL 0x0
RELCOUNT 0x90
Notably, the failing one does NOT have a SYMBOLIC section, but does have
PLTGOT, PLTRELSZ, PLTREL, JMPREL, and TEXTREL sections that are missing
from the working copy.
A manual inspection of the build logs reveals that they look somewhat
different, but nothing that jumps out at me as explaining the discrepancy
(and since the netbsd-libc build sequence does things in a similar but
slightly more manual fashion than just invoking build.sh, I'm not sure
which of the differences matter).
Full build logs can be made available, but I'd have to re-run both builds,
since a power failure caused a reboot and wiped /tmp a couple of days ago
(insert rant about UPSes with failing battery packs here).
--
Joel Aelwyn <fenton@debian.org> ,''`.
: :' :
`. `'
`-
Attachment:
signature.asc
Description: Digital signature