PATCH: Support Sun symbol versioning in libstdc++-v3

[Rainer Orth]

Jakub Jelinek <jakub@redhat.com> writes:

>> # This is a gcc built with both gas and gld
>> $ gcc -shared -static-libgcc -Wl,--version-script,libfunc.ver -h libfunc.so.1 -o libfunc.so.1 libfunc.c
>> $ pvs -dsv libfunc.so.1
>>         libfunc.so.1 [BASE]:
>>         FUNC_1.0:
>>                 FUNC_1.0;
>>         FUNC_2.0:               {FUNC_1.0}:
>>                 func;
>>                 FUNC_2.0;
>> # As you can see, func is *not* present in FUNC_1.0, although it should.
>
> The problem is that you used a Sun tool in the experiment, and that tool
> clearly has no clue about GNU symbol versioning.  You should have used readelf or objdump

While you're probably right about pvs, elfdump e.g. clearly understands
GNU style symbol versioning (seen e.g. in the sources).

> instead.  Doing the same (with s/-h /,-Wl,-soname,/) on Linux followed by:
> readelf -Wa libfunc.so.1 | grep func
>  0x000000000000000e (SONAME)             Library soname: [libfunc.so.1]
>      7: 000000000000059e    18 FUNC    GLOBAL DEFAULT   12 func@@FUNC_2.0
>      9: 000000000000058c    18 FUNC    GLOBAL DEFAULT   12 func@FUNC_1.0
>     40: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS libfunc.c
>     41: 000000000000059e    18 FUNC    LOCAL  DEFAULT   12 func_20
>     44: 000000000000058c    18 FUNC    LOCAL  DEFAULT   12 func_10
>     57: 000000000000059e    18 FUNC    GLOBAL DEFAULT   12 func@@FUNC_2.0
>     59: 000000000000058c    18 FUNC    GLOBAL DEFAULT   12 func@FUNC_1.0
>   000000: Rev: 1  Flags: BASE   Index: 1  Cnt: 1  Name: libfunc.so.1
> shows that both func@FUNC_1.0 and func@@FUNC_2.0 are present.  func@FUNC_1.0
> is a non-default symbol version, so new libraries/programs linking against this
> library will always pick func@@FUNC_2.0, but libraries/programs already
> linked against older version of the library which just had func@@FUNC_1.0
> will continue to work.

My primary point was not the investigation tools, which are just tools
here, but the observed runtime behaviour:

$ pvs -r func10-gcc
        libfunc.so.1 (FUNC_1.0);
        libc.so.1 (SUNWprivate_1.1, SYSVABI_1.3);
# But still runs the default version of func.
$ ./func10-gcc
FUNC_2.0
$ gcc -L. -R. -DFUNC_20 -o func20-gcc func.c -lfunc
$ pvs -r func20-gcc
        libfunc.so.1 (FUNC_2.0);
        libc.so.1 (SUNWprivate_1.1, SYSVABI_1.3);
$ ./func20-gcc
FUNC_2.0

Though both binaries were created exclusively with a GNU toolchain (gas
and gld 2.19), which is aware of the GNU symbol versioning extensions,
still the wrong function is called *at runtime* in the func10-gcc
binary, so ld.so.1 is unaware of the extensions and this cannot possibly
work.

That's my reason to disable this stuff wholesale if targetting
*-*-solaris2*, to avoid adding interfaces to the libraries that can
never be used because the runtime support is missing and outside the
control of the toolchain used to build the binaries.

	Rainer

-- 
-----------------------------------------------------------------------------
Rainer Orth, Center for Biotechnology, Bielefeld University