This is the mail archive of the binutils@sourceware.org mailing list for the binutils 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]

section index of the _end symbol


Hello,

I am looking at an interoperability issue between lld (LLVM's static
linker) and GNU ld on FreeBSD. Our C runtime library exports the _end
symbol, which is used by the brk()/sbrk() implementation. When libc.so
is linked using GNU ld, the _end symbol's section index (st_shndx) is
SHN_ABS, and when linked with lld it's the section index of .bss. When
linking an executable, GNU ld does not include _end in the dynamic
symbol table unless libc.so's _end symbol has an absolute value. Thus,
when using GNU ld to link an executable against an lld-linked libc.so,
_end is missing from the executable. I've verified this behaviour with
ld from binutils 2.17.50 and 2.30. I also hacked lld to emit _end with a
section index of SHN_ABS, so I'm reasonably confident that this detail
is responsible for the observed behaviour.

I've spent time reading the libbfd sources in an attempt to understand
the observed behaviour, but am rather stumped. I have two questions:
- Why does the _end symbol get a section index of SHN_ABS when linking a
  shared library? Presumably the value of the symbol will be modified by
  a runtime relocation, so SHN_ABS doesn't seem appropriate from my
  reading of the ELF spec.
- Why does GNU ld omit _end when linking an executable in the scenario
  described above?

Thanks in advance,
-Mark


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