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

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

[Vladimir Mezentsev]

  Hello Linux Experts,

The original problem is here:
30006 - Failure to build binutils-2.40 gprofng using gold
https://sourceware.org/bugzilla/show_bug.cgi?id=30006


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; }


% cat map.txt
GLIBC_2.0 {
     global:
        dlopen;
};

GLIBC_2.1 {
     global:
         dlopen;
};


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

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


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


My questions:

Is my test correct ?
if not:
   we need to interpose the dlopen functions from libdl.so.
   How can I do it correctly ?

If yes:
Is this a known compiler bug in gold ? If not, do I need to create one ?
   Is there a simple workaround ?

Thank you,
-Vladimir

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

[Cary Coutant]

> 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.

> % 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

Re: 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