section index of the _end symbol
H.J. Lu
hjl.tools@gmail.com
Tue May 29 20:18:00 GMT 2018
On Tue, May 29, 2018 at 1:11 PM, Mark Johnston <markj@freebsd.org> wrote:
> On Tue, May 29, 2018 at 12:23:09PM -0700, H.J. Lu wrote:
>> On Tue, May 29, 2018 at 12:17 PM, Mark Johnston <markj@freebsd.org> wrote:
>> > 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?
>> >
>>
>> Please try binutils master branch. I got
>>
>> [hjl@gnu-cfl-1 tmp]$ gcc x.c
>> [hjl@gnu-cfl-1 tmp]$ readelf -sW a.out| grep _end
>> 38: 0000000000403e18 0 NOTYPE LOCAL DEFAULT 18 __init_array_end
>> 54: 0000000000404028 0 NOTYPE GLOBAL DEFAULT 24 _end
>> [hjl@gnu-cfl-1 tmp]$
>
> Indeed, I see the new behaviour when using the binutils master branch.
> Our libc now gets:
>
> 194: 00000000005ee978 0 NOTYPE GLOBAL DEFAULT 29 _end@@FBSDprivate_1.0 (8)
>
> However, the behaviour I described is still present. That is, an
> executable linked against this libc doesn't contain the _end symbol
> in its dynamic symtab unless libc.so's _end has a st_shndx of SHN_ABS.
_end defined by the default linker script is special:
https://sourceware.org/bugzilla/show_bug.cgi?id=23161
Are _end in your libc.so and executable defined by the default linker script?
--
H.J.
More information about the Binutils
mailing list