Re: section index of the _end symbol

["H.J. Lu" <hjl dot tools at gmail dot com>]

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.