public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
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


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