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

[Anton Ertl]

Geoff Keating wrote:
> 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.

The computation is probably a little more complicated than just taking
paddr:

[anton@samhain tmp]$ gcc -O -Xlinker -Ttext -Xlinker 0x80000 xxx.c
[anton@samhain tmp]$ objdump -p a.out  

a.out:     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 0x00080000 paddr 0x00080000 align 2**16
         filesz 0x0000024c memsz 0x0000024c flags r-x
...
[anton@samhain tmp]$ LD_SHOW_AUXV=1 ./a.out
AT_PHDR:     0x70034
...

> 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.

Where do I find that?

> 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.

Which version?  I may be able to get the admin of the machine to try
it.

- anton