Re: [RFC] Hide autogenerated symbols when linking shared libraries

[Yuri Gribov <tetra2005 at gmail dot com>]

On Tue, May 1, 2018 at 5:00 PM, Nick Clifton <nickc@redhat.com> wrote:
> Hi Yuri,
>
>> Currently default linker script
>
> For which target(s) ?

Sorry, x86_64-linux-gnu (but I assume any ELF target which supports
shared libraries will have this issue).

>> generates several temporary symbols
>> which globally visible and unnecessarily increase size of dynamic
>> symtable:
>>   $ gcc -shared -fPIC -O2 tmp.c -o tmp.so
>>   $ readelf --dyn-syms -W tmp.so
>>   ...
>>      7: 0000000000201020     0 NOTYPE  GLOBAL DEFAULT   21 _edata
>>      9: 0000000000201028     0 NOTYPE  GLOBAL DEFAULT   22 _end
>>     10: 0000000000201020     0 NOTYPE  GLOBAL DEFAULT   22 __bss_start
>>
>> Is this intentional?
>
> Yes.  Sometime these symbols are used by the crt initialization code.
> For example, on bare metal systems the sbrk() function often uses the
> _end symbol as the starting address for the heap.
>
> Also tools like the dynamic loader, profilers, gdb and so on, sometimes
> make use of these symbols too.  So unless you are really short on space
> I would recommend leaving them in.

Ok, fair enough.  Still let me point out that presently these symbols
pollute binary interfaces of any shared library compiled with default
flags by GNU/LLVM tools.

Do you have any particular uses in mind?  I tried grepping glibc,
binutils-gdb or libgcc for bss_start but couldn't find anything which
would justify them having default visibility...

> PS.  You can always create your own linker script which does not define
> these symbols...

Thanks but I'm more worried about distros (I came across them while
investigating redundant symbols exported by Debian packages).  Asking
every package maintainer to use -Wl,--version-script won't scale very
well...

-Y