About gprofng/30006 - Failure to build binutils-2.40 gprofng using gold

[Vladimir Mezentsev]

  Hi Gary.

Thank you for your response.
My one comment below.

On 2/8/23 15:53, Cary Coutant wrote:
>> I prepared a small test that demonstrates the problem:
>>
>> % cat test.c
>> void *dlopen (const char *pathname, int mode)
>>     { return (void *) 0; }
>>
>> __attribute__ ((__symver__ ("dlopen@GLIBC_2.1")))
>> void *__collector_dlopen_2_1 (const char *pathname, int mode)
>>     { return (void *) 0; }
>>
>> __attribute__ ((__symver__ ("dlopen@GLIBC_2.0")))
>> void *__collector_dlopen_2_0 (const char *pathname, int mode)
>>     { return (void *) 0; }
>>
>> int main()
>>     { return 0; }
> The unbound copy of dlopen is the problem here. If you want a default
> version, you should use a symver attribute with an "@@" on that copy.

We don't want to have a default version. This may conflict with the 
default version in libdl.so
Before profiling, we export LD_PRELOAD=libgp-collector.so
and we want to interpose 3 functions:
  dlopen
  dlopen@GLIBC_2.0
  dlopen@GLIBC_2.1


If there are 3 calls in the profiled application, for example:

   void *(*dlopen_2_0)(const char* pathname, int mode) = dlvsym 
(RTLD_NEXT, "dlopen", "GLIBC_2.0");
   void *(*dlopen_2_1)(const char* pathname, int mode) = dlvsym 
(RTLD_NEXT, "dlopen", "GLIBC_2.1");

   dlopen("aaa", mode);
   dlopen_2_0("aaa", mode);
   dlopen_2_1("aaa", mode);

We need to catch each call.

How can we do it correctly ?

Thank you,
-Vladimir

>
>> % cat map.txt
>> GLIBC_2.0 {
>>       global:
>>          dlopen;
>> };
>>
>> GLIBC_2.1 {
>>       global:
>>           dlopen;
>> };
> Normally, I'd expect the GLIBC_2.1 { ... } block to include all of
> GLIBC_2.0, by naming the previous version after the closing brace.
> This is irrelevant to this problem, but you might want to think about
> that.
>
>> There are no problems with -fuse-ld=bfd:
>> % /opt/rh/gcc-toolset-10/root/bin/gcc -m32 test.c -Wl,--version-script
>> -Wl,map.txt  -fuse-ld=bfd
> You should also use -Wl,-E here. Otherwise, the symbols will not be
> exported to the dynamic symbol table.
>
>> The output of `nm` shows exactly what I expected:
>> % nm a.out | grep dlopen
>> 08049191 T __collector_dlopen_2_0
>> 08049187 T __collector_dlopen_2_1
>> 0804917d t dlopen
>> 08049191 t dlopen@GLIBC_2.0
>> 08049187 t dlopen@GLIBC_2.1
> Here, you're just dumping the static symbol table. Use "nm -D" to dump
> the dynamic symbol table, which is what you're really interested in.
>
>> But with -fuse-ld=gold:
>> % /opt/rh/gcc-toolset-10/root/bin/gcc -m32 test.c -Wl,--version-script
>> -Wl,map.txt  -fuse-ld=gold
>> /bin/ld.gold: warning: /tmp/cc6YCOol.o: unknown program property type
>> 0xc0010001 in .note.gnu.property section
>> /bin/ld.gold: warning: using 'GLIBC_2.0' as version for 'dlopen' which
>> is also named in version 'GLIBC_2.1' in script
>> /bin/ld.gold: error: /tmp/cc6YCOol.o: multiple definition of 'dlopen'
>> /bin/ld.gold: /tmp/cc6YCOol.o: previous definition here
>> collect2: error: ld returned 1 exit status
> If you leave out the unbound version of dlopen, or symver it to a
> third version node, this should work.
>
>> My questions:
>>
>> Is my test correct ?
> Sorry, I really don't know. The ld manual doesn't really cover this
> case, nor do any of the ld test cases that I could find. BFD ld and
> gold differ here, and I don't know whether or not to consider that a
> bug.
>
>> if not:
>>     we need to interpose the dlopen functions from libdl.so.
>>     How can I do it correctly ?
> If you bind every version of dlopen to a different version node, it
> should work in both linkers.
>
>> If yes:
>> Is this a known compiler bug in gold ? If not, do I need to create one ?
>>     Is there a simple workaround ?
> I hope binding the base version of dlopen to a separate version node
> works for you. Whether to call that a workaround or a fix to your
> testcase, I'm not sure.
>
> -cary