Evolution of ELF symbol management

[Florian Weimer]

On 10/25/2016 05:37 PM, Joseph Myers wrote:
> On Tue, 25 Oct 2016, Florian Weimer wrote:
>
>>> There are a few existing __libc_foo exports at public symbol versions.  Do
>>> all those satisfy the rule that where both foo and __libc_foo exist, the
>>> latest version of foo and the latest version of __libc_foo are aliases or
>>> otherwise have the same semantics?  (It would seem very confusing for old
>>> and new __libc_* symbols to follow different rules in that regard.)
>>
>> I found a few symbols which differs in the exported version.  The unprefixed
>> symbol has a regular version, and the prefixed one appears as GLIBC_PRIVATE.
>> These are:
>>
>> clntudp_bufcreate
>> fork
>> longjmp
>> pread
>> pwrite
>> secure_getenv
>> siglongjmp
>> system
>> vfork
>
> My concern is mainly about __libc_* symbols at public versions, not
> GLIBC_PRIVATE, since we can freely change the ABIs for __libc_* at
> GLIBC_PRIVATE if those are confusing.

I put together the attached Python script to check for collisions.  It 
reports anything that is not UNDEF or GLIBC_PRIVATE and where the 
__libc_-prefixed and non-prefixed symbols have different values.  It 
reports some mismatches in libasan, so I think it works.  It does not 
flag anything for glibc on i386 and x86_64 with current master.

The script has a hard-coded path to elfutils readelf, it needs Mark's 
recent addition of the --symbols=SECTION argument.

So I think we are good on this front.

>> This is less relevant for functions in non-standard headers (which
>> applications would not include accidentally), but if we add something to
>> <stdio.h> (under _GNU_SOURCE) which is ripe for collisions, we need to somehow
>> make sure that a user-defined function of the same name does not end up
>> interposing the alias.
>
> Same name and type, that is; if the type is wrong and the header
> declaration is visible, a compile-time error will occur.

Good point.  We could add artificial transparent unions to arguments to 
make it harder to write a matching definition, even with current GCC 
versions.

> There is always the option of having the installed headers be generated
> files, so the source tree has .h.in files that contain some sort of
> annotations for use by a special glibc-specific preprocessor that does
> things the C preprocessor cannot - converting something that looks like a
> C macro call (say) into function declarations, __REDIRECT calls - and
> function-like macro definitions.  Of course then you need to get those
> headers generated at an early stage in the glibc build.

Interesting idea.

We could generate a different set of such headers of internal glibc user 
if required.  This could allow us to compile more parts of glibc as 
standard C sources, without mangling of public symbols, which would help 
with things like unit testing and fuzz testing.

>> I think this leads to the question whether we should prefer __ over __libc_
>> after all because as part of fixing the glibc-internal linknamespace issues,
>> we often added a __ symbol with a public version (but sometimes a
>
> We shouldn't have added them with public versions, just internally (and
> only at GLIBC_PRIVATE if needed by a separate library from the
> definition).

It's a bit too late for that, unfortunately.

Florian

-------------- next part --------------
A non-text attachment was scrubbed...
Name: glibc-libc-symbols-conflicts.py
Type: text/x-python
Size: 2280 bytes
Desc: not available
URL: <http://sourceware.org/pipermail/libc-alpha/attachments/20161121/0826228e/attachment.py>