From: Tom de Vries <tdevries@suse.de>
To: Simon Marchi <simark@simark.ca>, gdb-patches@sourceware.org
Subject: Re: [pushed] [gdb/testsuite] Fix gdb.threads/dlopen-libpthread.exp for upstream glibc
Date: Tue, 10 Jan 2023 18:23:32 +0100 [thread overview]
Message-ID: <174dba84-bac5-af4c-cd2b-85257f57b025@suse.de> (raw)
In-Reply-To: <7bb6a09d-b915-c855-804d-4c3b13e38b37@simark.ca>
[-- Attachment #1: Type: text/plain, Size: 5673 bytes --]
On 1/4/23 17:54, Simon Marchi wrote:
>
>
> On 12/30/22 10:54, Tom de Vries via Gdb-patches wrote:
>> On ubuntu 22.04.1 x86_64, I run into:
>> ...
>> (gdb) info probes all rtld rtld_map_complete^M
>> No probes matched.^M
>> (gdb) XFAIL: gdb.threads/dlopen-libpthread.exp: info probes all rtld rtld_map_complete
>> UNTESTED: gdb.threads/dlopen-libpthread.exp: no matching probes
>> ...
>> This has been filed as PR testsuite/17016.
>>
>> The problem is that the name rtld_map_complete is used, which was only
>> available in Fedora 17, and upstream the name map_complete was used.
>>
>> In the email thread discussing a proposed patch (
>> https://sourceware.org/legacy-ml/gdb-patches/2014-09/msg00712.html ) it was
>> suggested to make the test-case handle both names.
>>
>> So, handle both names: map_complete and rtld_map_complete.
>>
>> This exposes the following FAIL:
>> ...
>> (gdb) info sharedlibrary^M
>> From To Syms Read Shared Object Library^M
>> $hex $hex Yes /lib64/ld-linux-x86-64.so.2^M
>> $hex $hex Yes (*) /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0^M
>> $hex $hex Yes /lib/x86_64-linux-gnu/libc.so.6^M
>> $hex $hex Yes /lib/x86_64-linux-gnu/libdl.so.2^M
>> $hex $hex Yes /lib/x86_64-linux-gnu/libpthread.so.0^M
>> (*): Shared library is missing debugging information.^M
>> (gdb) FAIL: gdb.threads/dlopen-libpthread.exp: libpthread.so not found
>> ...
>> due to using a glibc (v2.35) that has libpthread integrated into libc.
>
> On my Ubuntu 22.04, I now get:
>
>
> info sharedlibrary^M
> From To Syms Read Shared Object Library^M
> 0x00007ffff7fc5090 0x00007ffff7fee335 Yes (*) /lib64/ld-linux-x86-64.so.2^M
> 0x00007ffff7da7700 0x00007ffff7f39abd Yes (*) /lib/x86_64-linux-gnu/libc.so.6^M
> 0x00007ffff7fb70a0 0x00007ffff7fb721f Yes /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/dlopen-libpthread/dlopen-libpthread.so^M
> (*): Shared library is missing debugging information.^M
> (gdb) FAIL: gdb.threads/dlopen-libpthread.exp: libpthread.so found
>
> And this is what I expect, given that libpthread.so doesn't exist
> anymore. I don't understand the output you pasted above. My
> testsuite/outputs/gdb.threads/dlopen-libpthread/dlopen-libpthread.so
> doesn't depend on libpthread.so.0. I think that libpthread.so.0 is just
> there fore backwards compatibility with old binaries that refer to it,
> but any newly compiled binary will not depend on it. So the binary
> compiled by the test should not. I also don't understand where the
> libgtk3-noscd.so.0 library comes from, it's a bit strange to have that
> in a test binary.
>
>>
>> Fix this by changing the FAIL into UNSUPPORTED.
>>
>> Tested on x86_64-linux.
>>
>> Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=17016
>> ---
>> .../gdb.threads/dlopen-libpthread.exp | 35 +++++++++++++------
>> 1 file changed, 25 insertions(+), 10 deletions(-)
>>
>> diff --git a/gdb/testsuite/gdb.threads/dlopen-libpthread.exp b/gdb/testsuite/gdb.threads/dlopen-libpthread.exp
>> index 5c3d8a34c30..dcc48260e88 100644
>> --- a/gdb/testsuite/gdb.threads/dlopen-libpthread.exp
>> +++ b/gdb/testsuite/gdb.threads/dlopen-libpthread.exp
>> @@ -40,22 +40,37 @@ if { ![runto_main] } {
>> return -1
>> }
>>
>> -set test "info probes all rtld rtld_map_complete"
>> -gdb_test_multiple $test $test {
>> - -re "\[ \t\]rtld_map_complete\[ \t\]+0x\[0-9a-f\]+.*\r\n$gdb_prompt $" {
>> - pass $test
>> - }
>> - -re "No probes matched\\.\r\n$gdb_prompt $" {
>> - xfail $test
>> - untested "no matching probes"
>> - return
>> +set probe_names {}
>> +# Fedora 17 name. There's specific code in
>> +# svr4_find_and_create_probe_breakpoints to deal with this.
>> +lappend probe_names rtld_map_complete
>> +# Upstream name.
>> +lappend probe_names map_complete
>> +
>> +set have_probe 0
>> +foreach probe_name $probe_names {
>> + set cmd "info probes all rtld ^$probe_name$"
>> + gdb_test_multiple $cmd "" {
>> + -re -wrap "\[ \t\]$probe_name\[ \t\]+0x\[0-9a-f\]+.*" {
>> + set have_probe 1
>> + }
>> + -re -wrap "No probes matched\\." {
>> + }
>> }
>> }
>>
>> +if { !$have_probe } {
>> + untested "no matching probes"
>> +}
>
> I think you are missing a "return" here, to match the previous behavior?
>
Hi Simon,
Ack.
>> +
>> set test "libpthread.so not found"
>> gdb_test_multiple "info sharedlibrary" $test {
>> -re "/libpthread\\.so.*\r\n$gdb_prompt $" {
>> - fail $test
>> + # With newer glibc, libpthread has been integrated into glibc so we
>> + # can expect it to be already loaded at main. This means we no longer
>> + # excercise the scenario we're trying to trigger, but continue
>> + # nevertheless.
>> + unsupported $test
>
> Given this comment here, it looks like your something in your
> environment makes it so libpthread.so.0 is loaded at startup, but I
> don't think it's supposed to happen in a "clean" state. Indeed,
> libpthread has been merged into libc, but that doesn't mean that any
> program will show libpthread.so.0 as loaded. There must be something
> strange happening here. Did you have some LD_PRELOAD set or something?
you're right, it's a LD_PRELOAD thing, due to using unity desktop on
ubuntu, which gets me:
...
$ echo $LD_PRELOAD
libgtk3-nocsd.so.0
...
I thought I checked LD_PRELOAD, but evidently didn't and mis-analyzed
the problem.
On the ubuntu machine I can reproduce the FAIL you're seeing when using
"LD_PRELOAD= make check", as well as on openSUSE Tumbleweed where I
don't have the LD_PRELOAD.
Attached patch fixes things.
WDYT?
Thanks,
- Tom
[-- Attachment #2: 0001-gdb-testsuite-Fix-gdb.threads-dlopen-libpthread.exp-.patch --]
[-- Type: text/x-patch, Size: 5169 bytes --]
From 74e795b9250610aef6364fb523f0aa839b47e17a Mon Sep 17 00:00:00 2001
From: Tom de Vries <tdevries@suse.de>
Date: Mon, 9 Jan 2023 10:41:12 +0100
Subject: [PATCH] [gdb/testsuite] Fix gdb.threads/dlopen-libpthread.exp for
upstream glibc, again
On an x86_64 laptop running ubuntu 22.04.1 with unity desktop:
...
$ echo $XDG_CURRENT_DESKTOP
Unity:Unity7:ubuntu
...
I have:
...
$ echo $LD_PRELOAD
libgtk3-nocsd.so.0
...
due to package gtk3-nocsd, a package recommended by unity-session.
Consequently, for each exec these dependencies are pulled in, including
libpthread.so.0:
...
$ lddtree /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0
libgtk3-nocsd.so.0 => /lib/x86_64-linux-gnu/libgtk3-nocsd.so.0 (interpreter => none)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6
ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
...
So, while test-case gdb.threads/dlopen-libpthread.exp appears to run ok:
...
# of expected passes 12
# of unsupported tests 1
...
with LD_PRELOAD="" we have instead:
...
(gdb) PASS: gdb.threads/dlopen-libpthread.exp: continue to breakpoint: notify
info sharedlibrary^M
From To Syms Read Shared Object Library^M
$hex $hex Yes /lib64/ld-linux-x86-64.so.2^M
$hex $hex Yes /lib/x86_64-linux-gnu/libc.so.6^M
$hex $hex Yes dlopen-libpthread.so^M
(gdb) FAIL: gdb.threads/dlopen-libpthread.exp: libpthread.so found
...
The problem is that libpthread is expected as dependency of
dlopen-libpthread.so, but it's missing:
...
$ lddtree dlopen-libpthread.so
dlopen-libpthread.so => ./dlopen-libpthread.so (interpreter => none)
libc.so.6 => $outputs/gdb.threads/dlopen-libpthread/dlopen-libpthread.so.d/libc.so.6
ld-linux-x86-64.so.2 => /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
...
due to having glibc 2.35, which has lipthread integrated into glibc.
Fix this by:
- adding a proc has_dependency
- using [has_dependency $exec libpthread.so] as hint that libpthread
may be preloaded
- using ![has_dependency $shlib libpthread.so] to detect that
the libpthread.so dependency is missing.
Tested on x86_64-linux, with and without LD_PRELOAD="".
---
.../gdb.threads/dlopen-libpthread.exp | 30 +++++++++++++++----
gdb/testsuite/lib/gdb.exp | 17 +++++++++++
2 files changed, 41 insertions(+), 6 deletions(-)
diff --git a/gdb/testsuite/gdb.threads/dlopen-libpthread.exp b/gdb/testsuite/gdb.threads/dlopen-libpthread.exp
index 0b325ce622f..8259da3d682 100644
--- a/gdb/testsuite/gdb.threads/dlopen-libpthread.exp
+++ b/gdb/testsuite/gdb.threads/dlopen-libpthread.exp
@@ -61,16 +61,32 @@ foreach probe_name $probe_names {
if { !$have_probe } {
untested "no matching probes"
+ return -1
+}
+
+# We link the exec without -lpthread, but libpthread.so may already be loaded at main
+# due to LD_PRELOAD.
+set libpthread_maybe_preloaded 0
+set binfile [standard_output_file $executable]
+if { [has_dependency $binfile libpthread\\.so] == 1 } {
+ set libpthread_maybe_preloaded 1
+}
+
+# We link the shlib with -lpthread, but since glibc 2.34 libpthread has been
+# merged with libc, so libpthread.so may not be a dependency.
+set libpthread_missing 0
+if { [has_dependency $binfile libpthread\\.so] == 0 } {
+ set libpthread_missing 1
}
set test "libpthread.so not found"
gdb_test_multiple "info sharedlibrary" $test {
-re "/libpthread\\.so.*\r\n$gdb_prompt $" {
- # With newer glibc, libpthread has been integrated into glibc so we
- # can expect it to be already loaded at main. This means we no longer
- # excercise the scenario we're trying to trigger, but continue
- # nevertheless.
- unsupported $test
+ if { $libpthread_maybe_preloaded } {
+ unsupported $test
+ } else {
+ fail $test
+ }
}
-re "/libc\\.so.*\r\n$gdb_prompt $" {
pass $test
@@ -85,4 +101,6 @@ gdb_breakpoint "notify"
# Cannot find new threads: generic error
gdb_continue_to_breakpoint "notify" ".* notify-here .*"
-gdb_test "info sharedlibrary" {/libpthread\.so.*} "libpthread.so found"
+if { !$libpthread_missing } {
+ gdb_test "info sharedlibrary" {/libpthread\.so.*} "libpthread.so found"
+}
diff --git a/gdb/testsuite/lib/gdb.exp b/gdb/testsuite/lib/gdb.exp
index c41d4698d66..39dfa67c344 100644
--- a/gdb/testsuite/lib/gdb.exp
+++ b/gdb/testsuite/lib/gdb.exp
@@ -9355,5 +9355,22 @@ proc decompress_bz2 { bz2 } {
return $copy
}
+# Return 1 if the output of "ldd FILE" contains regexp DEP, 0 if it doesn't,
+# and -1 if there was a problem running the command.
+
+proc has_dependency { file dep } {
+ set ldd [gdb_find_ldd]
+ set command "$ldd $file"
+ set result [remote_exec host $command]
+ set status [lindex $result 0]
+ set output [lindex $result 1]
+ verbose -log "status of $command is $status"
+ verbose -log "output of $command is $output"
+ if { $status != 0 || $output == "" } {
+ return -1
+ }
+ return [regexp $dep $output]
+}
+
# Always load compatibility stuff.
load_lib future.exp
base-commit: 8ec0b0b5df0ebe28c32900afc7ae8ff22b21f381
--
2.35.3
next prev parent reply other threads:[~2023-01-10 17:23 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-12-30 15:54 Tom de Vries
2023-01-04 16:54 ` Simon Marchi
2023-01-10 17:23 ` Tom de Vries [this message]
2023-01-10 18:05 ` Simon Marchi
2023-01-11 9:17 ` Tom de Vries
2023-01-11 16:20 ` Simon Marchi
2023-01-11 17:20 ` Tom de Vries
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=174dba84-bac5-af4c-cd2b-85257f57b025@suse.de \
--to=tdevries@suse.de \
--cc=gdb-patches@sourceware.org \
--cc=simark@simark.ca \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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).