section index of the _end symbol

[Mark Johnston]

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.