section index of the _end symbol

[H.J. Lu]

On Tue, May 29, 2018 at 2:00 PM, Mark Johnston <markj@freebsd.org> wrote:
> On Tue, May 29, 2018 at 01:18:23PM -0700, H.J. Lu wrote:
>> 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?
>
> Indeed, I'm not using a custom linker script for either of them.
>
> Regarding the bug, our libc.so initializes curbrk to the address of the
> executable's _end, so we currently rely on it being present in .dynsym.

Please provide this information to

https://sourceware.org/bugzilla/show_bug.cgi?id=23161

-- 
H.J.