* About gprofng/30006 - Failure to build binutils-2.40 gprofng using gold
@ 2023-02-07 2:47 Vladimir Mezentsev
2023-02-08 23:53 ` Cary Coutant
0 siblings, 1 reply; 3+ messages in thread
From: Vladimir Mezentsev @ 2023-02-07 2:47 UTC (permalink / raw)
To: binutils
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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: About gprofng/30006 - Failure to build binutils-2.40 gprofng using gold
2023-02-07 2:47 About gprofng/30006 - Failure to build binutils-2.40 gprofng using gold Vladimir Mezentsev
@ 2023-02-08 23:53 ` Cary Coutant
2023-02-10 8:19 ` Vladimir Mezentsev
0 siblings, 1 reply; 3+ messages in thread
From: Cary Coutant @ 2023-02-08 23:53 UTC (permalink / raw)
To: Vladimir Mezentsev; +Cc: binutils
> 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
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: About gprofng/30006 - Failure to build binutils-2.40 gprofng using gold
2023-02-08 23:53 ` Cary Coutant
@ 2023-02-10 8:19 ` Vladimir Mezentsev
0 siblings, 0 replies; 3+ messages in thread
From: Vladimir Mezentsev @ 2023-02-10 8:19 UTC (permalink / raw)
To: Cary Coutant; +Cc: binutils
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
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2023-02-10 8:19 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-02-07 2:47 About gprofng/30006 - Failure to build binutils-2.40 gprofng using gold Vladimir Mezentsev
2023-02-08 23:53 ` Cary Coutant
2023-02-10 8:19 ` Vladimir Mezentsev
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).