[RFC] Hide autogenerated symbols when linking shared libraries

[Yuri Gribov]

On Thu, May 3, 2018 at 1:51 PM, Maksim Kozlov <maksim.e.kozlov@gmail.com> wrote:
>>
>> > 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...
>>
>> Not really - I was just speaking in generalities.  It may well turn out
>> that for, say x86_64 Linux based systems, these symbols are not needed.
>> But I would be very wary of removing them without a lot of testing first
>> as this is exactly the kind of thing that can break systems in unexpected,
>> and unanticipated ways.
>>
>
> Hi all,

Hi Max,

> I'm not expert in this area, and I hope I understand right what you are
> talking about. I can say that these symbols are widely used in Linux kernel,
> RTEMS system and Newlib C library.

Just to clarify - we discussed removing these symbols from dynamic
symbol table of ELF shared libraries (so it's limited to Linux/BSD and
baremetals are out of question). My point was that standard
tools/libraries do not access them (at least not through dynamic
symtab).

More importantly, as Nick pointed out, the whole issue is more of
cosmetics/consistency (performance loss is negligible and runtime
symbol collisions are not important, precisely because no tool seems
to access these symbols) so the whole discussion is rather
theoretical.

> Yuri, you can try to do grep on sources
> of these projects to see if this is what you are talking about. Also, from
> my personal experience I can add that these symbols are widely used in many
> "selfmade" bare-metal embedded systems.
> Hope this is relevant information.

I must admit that I'm not an expert in any of those :( but at least in
newlib's case all uses seem to be in startup code (crt0) so there
should be no need to export them through dynamic symtab. I'd also be
surprised if kernel had to access anything besides ELF program headers
(and maybe dynamic section).

-Y