Re: [(nowhere)] libc/1808: ld.so on powerpc-redhat-linux-gnu with ld -Ttext ...

[Geoff Keating <geoffk at cygnus dot com>]

> From: Andreas Jaeger <aj@suse.de>
> Date: 05 Jul 2000 20:17:13 +0200

> When I link a program -Ttext 0x10000 (or any other value below
> 0x10000000, but not between 0x10000000 and 0x80000000), executing the
> program produces a segfault before entering main.  Gdb and
> /proc/.../maps indicate that the segfault happens in code belonging to
> ld.so.

What happens is that if I use -Ttext=0x10000, I get a file like this:

t:     file format elf32-powerpc

Program Header:
    PHDR off    0x00000034 vaddr 0x00010034 paddr 0x00000000 align 2**2
         filesz 0x000000e0 memsz 0x000000e0 flags r-x
  INTERP off    0x00020114 vaddr 0x10000114 paddr 0x10000114 align 2**0
         filesz 0x0000000d memsz 0x0000000d flags r--
    LOAD off    0x00010000 vaddr 0x00010000 paddr 0x00010000 align 2**16
         filesz 0x000001dc memsz 0x000001dc flags r-x

but the kernel produces this in the auxiliary vector:

$9 = {a_type = 3, a_un = {a_val = 52, a_ptr = 0x34, a_fcn = 0x34}}

(you can display this more easily by writing 'LD_SHOW_AUXV=1 ./t',
for /bin/ls I get

AT_PHDR:     0x1800034

but for the test program I get

AT_PHDR:     0x34

and it should be 0x10034.)

No doubt this is due to the physical segment offset being 0, although
I would have expected AT_PHDR being 0 then.

I think the physical segment offset thing is a side-effect of the way
the linker scripts work.  You might try it with current devo first,
which has a completely different script for ppc.

I also think the kernel should not look at the physical address at
all.  You'll be happy to know that this code was rewritten for later
kernels, so maybe that fixed it.

-- 
- Geoffrey Keating <geoffk@cygnus.com>