This is the mail archive of the
libc-hacker@sourceware.cygnus.com
mailing list for the glibc project.
bug involving strip, etc.
- To: libc-hacker@cygnus.com
- Subject: bug involving strip, etc.
- From: Geoff Keating <geoffk@ozemail.com.au>
- Date: Mon, 14 Dec 1998 23:45:26 +1100
Some time ago, someone reported a bug involving stripped executables.
It's now started happening to me, so I debugged it a little.
The executables in question have the following weird structure:
ELF Header:
Magic: 7f 45 4c 46 01 02 01 00 00 00 00 00 00 00 00 00
Type: EXEC (Executable file)
Machine: PowerPC
Version: 0x1
Data: ELFDATA2MSB (big endian)
Entry point address: 0x1800b5c
Start of program headers: 52 (bytes into file)
Start of section headers: 18500 (bytes into file)
Flags: 0x0
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: 27
Section header string table index: 26
Program Headers:
Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align
PHDR 0x000034 0x01840034 0x01800034 0x000c0 0x000c0 R E 0x4
INTERP 0x000114 0x01800114 0x01800114 0x0000d 0x0000d R 0x1
[Requesting program interpreter: /lib/ld.so.1]
LOAD 0x000000 0x01800000 0x01800000 0x043f8 0x043f8 R E 0x10000
LOAD 0x000034 0x01840034 0x018443f8 0x04584 0x04824 RWE 0x10000
DYNAMIC 0x00441c 0x0184441c 0x0184441c 0x000a8 0x000a8 RW 0x4
NOTE 0x000130 0x01800130 0x01800130 0x00020 0x00020 R 0x10
As you can see, the program header is 52 bytes into the file, but is
65588 bytes into the executable image.
The kernel (my 2.0.33 kernel, in src/fs/binfmt_elf.c) does this when
it's building the ET_PHDR auxv entry:
NEW_AUX_ENT (AT_PHDR, load_addr + exec->e_phoff);
now, this produces the _file_ offset of the entry, not the _memory_
offset.
Since glibc uses the address of the program header to determine where
the program starts in memory, this naturally causes problems.
This can be fixed in the kernel by just doing a little more work;
there's already a loop over the program header in do_load_elf_binary,
just after the comment
/* Now we do a little grungy work by mmaping the ELF image into
the correct location in memory. At this point, we assume that
the image should be loaded at fixed address, not at a variable
address. */
so it's easy enough to make a note of the program header's memory
location and pass it down to create_elf_tables.
It might also be good to fix the binutils, except that I can't
reproduce the problem now :-(.
--
Geoffrey Keating <geoffk@ozemail.com.au>