-nostartfiles for -shared on ELF

-nostartfiles for -shared on ELF

[Mathieu Lacage]

hi,

I got a bit curious when I found out about the following testcase:
[mlacage@diese test]$ cat >test.c
int foo (void)
{}
[mlacage@diese test]$ cc  -fpic  -c -o test.o test.c
[mlacage@diese test]$ ld -shared -nostartfiles -o libtest.so test.o
[mlacage@diese test]$ readelf -l ./libtest.so

Elf file type is DYN (Shared object file)
Entry point 0x804812c
There are 3 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000094 0x08048094 0x08048094 0x01104 0x01104 RWE 0x4
  DYNAMIC        0x001134 0x08049134 0x08049134 0x00058 0x00058 RW  0x4
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4

[mlacage@diese test]$ ld -shared -o libtest.so test.o
[mlacage@diese test]$ readelf -l ./libtest.so

Elf file type is DYN (Shared object file)
Entry point 0x14c
There are 4 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x000000 0x00000000 0x00000000 0x00154 0x00154 R E 0x1000
  LOAD           0x000154 0x00001154 0x00001154 0x00064 0x00064 RW  0x1000
  DYNAMIC        0x000154 0x00001154 0x00001154 0x00058 0x00058 RW  0x4
  GNU_STACK      0x000000 0x00000000 0x00000000 0x00000 0x00000 RW  0x4

This is clearly a reduced testcase because using -nostartfile in this
case will not generate a very useful library but I did stumble upon
the same behavior while generating a shared library of mine which
wants to make use of -nostartfile but which also wants to ensure that
the offset of the first PT_LOAD is zero. Using this option seems to
trigger a fairly major change in the structure of the resulting ELF
binary:
1) PT_LOAD does not extend to offset 0 (it starts a couple hundred bytes later)
2) the entry point looks like the entry point of an executable (i.e.,
the library seems to be linked as if its base address was 0x804812c
rather than the customary zero on linux-x86)
3) there is only one PT_LOAD and it is RWE, even though it contains RO code.

Now, I tried to figure out why I am getting this exactly by reading a
bit the bfd code and glibc init/fini code but, well, without much
success so, I was hoping someone could help me a bit before I start
rebuilding my binutils ld and try to trace the behavior of bfd/elf.c
with gdb/printf.

Mathieu
-- 
Mathieu Lacage <mathieu.lacage@gmail.com>

Re: -nostartfiles for -shared on ELF

[Mathieu Lacage]

On Mon, Feb 2, 2009 at 5:41 PM, Mathieu Lacage <mathieu.lacage@gmail.com> wrote:
> Now, I tried to figure out why I am getting this exactly by reading a
> bit the bfd code and glibc init/fini code but, well, without much
> success so, I was hoping someone could help me a bit before I start
> rebuilding my binutils ld and try to trace the behavior of bfd/elf.c
> with gdb/printf.

Erm, what I meant is that I was hoping someone would know off the top
of their head what I can do to use -nostartfile _and_ ensure that the
first PT_LOAD covers offset zero but I could settle for an explanation
of the behavior of the linker/gcc/glibc start files :)

Mathieu
-- 
Mathieu Lacage <mathieu.lacage@gmail.com>

Re: -nostartfiles for -shared on ELF

[Ian Lance Taylor]

Mathieu Lacage <mathieu.lacage@gmail.com> writes:

> [mlacage@diese test]$ cc  -fpic  -c -o test.o test.c
> [mlacage@diese test]$ ld -shared -nostartfiles -o libtest.so test.o
> [mlacage@diese test]$ readelf -l ./libtest.so

-nostartfiles is a compiler option, not a linker option.  I would
expect that passing -nostartfiles to the linker would be treated as
passing -n -o startfiles.  Then the -o option is overridden by your
later -o libtest.so.  So you are effectively invoking the linker with
the -n option, q.v.

Ian