bug involving strip, etc.

[Geoff Keating <geoffk@ozemail.com.au>]

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>