This is the mail archive of the
gcc-help@gcc.gnu.org
mailing list for the GCC project.
-nostartfiles for -shared on ELF
- From: Mathieu Lacage <mathieu dot lacage at gmail dot com>
- To: gcc-help at gcc dot gnu dot org
- Date: Mon, 2 Feb 2009 17:41:31 +0100
- Subject: -nostartfiles for -shared on ELF
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>