section index of the _end symbol

[H.J. Lu]

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]$


-- 
H.J.