This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]