[pushed] [gdb/testsuite] Fix gdb.threads/dlopen-libpthread.exp for upstream glibc

[pushed] [gdb/testsuite] Fix gdb.threads/dlopen-libpthread.exp for upstream glibc

[Tom de Vries]

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.

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"
+}
+
 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
     }
     -re "/libc\\.so.*\r\n$gdb_prompt $" {
 	pass $test

base-commit: d6246a8730fad9edcb972c1f689a13bb16640483
-- 
2.35.3

Re: [pushed] [gdb/testsuite] Fix gdb.threads/dlopen-libpthread.exp for upstream glibc

[Simon Marchi]

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?

> +
>  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?

Simon

Re: [pushed] [gdb/testsuite] Fix gdb.threads/dlopen-libpthread.exp for upstream glibc

[Tom de Vries]

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

Re: [pushed] [gdb/testsuite] Fix gdb.threads/dlopen-libpthread.exp for upstream glibc

[Simon Marchi]

> Attached patch fixes things.
> 
> WDYT?
> 
> Thanks,
> - Tom


Here:

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

Ok, so this works because ldd is influenced by LD_PRELOAD, I didn't
know.

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

The two has_dependency calls use $binfile.  Should one of them use
$binfile_lib?  The second one I think.

Simon

Re: [pushed] [gdb/testsuite] Fix gdb.threads/dlopen-libpthread.exp for upstream glibc

[Tom de Vries]

On 1/10/23 19:05, Simon Marchi wrote:
>> Attached patch fixes things.
>>
>> WDYT?
>>
>> Thanks,
>> - Tom
> 
> 
> Here:
> 
>> # 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
>> }
> 
> Ok, so this works because ldd is influenced by LD_PRELOAD, I didn't
> know.
> 

Yes, while lddtree is not, which had me confused for a while.

>>
>> # 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
>> }
> 
> The two has_dependency calls use $binfile.  Should one of them use
> $binfile_lib?  The second one I think.

Yes, thanks for catching this.

I'll commit after another build & test cycle.

Thanks,
- Tom

Re: [pushed] [gdb/testsuite] Fix gdb.threads/dlopen-libpthread.exp for upstream glibc

[Simon Marchi]

On 1/11/23 04:17, Tom de Vries via Gdb-patches wrote:
> On 1/10/23 19:05, Simon Marchi wrote:
>>> Attached patch fixes things.
>>>
>>> WDYT?
>>>
>>> Thanks,
>>> - Tom
>>
>>
>> Here:
>>
>>> # 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
>>> }
>>
>> Ok, so this works because ldd is influenced by LD_PRELOAD, I didn't
>> know.
>>
> 
> Yes, while lddtree is not, which had me confused for a while.
> 
>>>
>>> # 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
>>> }
>>
>> The two has_dependency calls use $binfile.  Should one of them use
>> $binfile_lib?  The second one I think.
> 
> Yes, thanks for catching this.
> 
> I'll commit after another build & test cycle.

Hmm, I still see the failure.  I think the second has_dependency doesn't
work.  It returns 1 when it shouldn't, because of the
dlopen-libpthread.so.d line:

    output of ldd /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/dlopen-libpthread/dlopen-libpthread.so is
            linux-vdso.so.1 (0x00007ffc809ee000)^M
            libc.so.6 => /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/dlopen-libpthread/dlopen-libpthread.so.d/libc.so.6 (0x00007f0a5cf03000)^M
            /lib64/ld-linux-x86-64.so.2 (0x00007f0a5d132000)^M

This directory is created by build_executable_own_libs in
lib/prelink-support.exp (used by the test).

Tweaking the regexp to include a forward slash makes it work for me:

  diff --git a/gdb/testsuite/gdb.threads/dlopen-libpthread.exp b/gdb/testsuite/gdb.threads/dlopen-libpthread.exp
  index 134265ff470..c97e0284475 100644
  --- a/gdb/testsuite/gdb.threads/dlopen-libpthread.exp
  +++ b/gdb/testsuite/gdb.threads/dlopen-libpthread.exp
  @@ -68,14 +68,14 @@ if { !$have_probe } {
   # due to LD_PRELOAD.
   set libpthread_maybe_preloaded 0
   set binfile [standard_output_file $executable]
  -if { [has_dependency $binfile libpthread\\.so] == 1 } {
  +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_lib libpthread\\.so] == 0 } {
  +if { [has_dependency $binfile_lib /libpthread\\.so] == 0 } {
       set libpthread_missing 1
   }

Simon

Re: [pushed] [gdb/testsuite] Fix gdb.threads/dlopen-libpthread.exp for upstream glibc

[Tom de Vries]

On 1/11/23 17:20, Simon Marchi wrote:
> 
> 
> On 1/11/23 04:17, Tom de Vries via Gdb-patches wrote:
>> On 1/10/23 19:05, Simon Marchi wrote:
>>>> Attached patch fixes things.
>>>>
>>>> WDYT?
>>>>
>>>> Thanks,
>>>> - Tom
>>>
>>>
>>> Here:
>>>
>>>> # 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
>>>> }
>>>
>>> Ok, so this works because ldd is influenced by LD_PRELOAD, I didn't
>>> know.
>>>
>>
>> Yes, while lddtree is not, which had me confused for a while.
>>
>>>>
>>>> # 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
>>>> }
>>>
>>> The two has_dependency calls use $binfile.  Should one of them use
>>> $binfile_lib?  The second one I think.
>>
>> Yes, thanks for catching this.
>>
>> I'll commit after another build & test cycle.
> 
> Hmm, I still see the failure.  I think the second has_dependency doesn't
> work.  It returns 1 when it shouldn't, because of the
> dlopen-libpthread.so.d line:
> 
>      output of ldd /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/dlopen-libpthread/dlopen-libpthread.so is
>              linux-vdso.so.1 (0x00007ffc809ee000)^M
>              libc.so.6 => /home/smarchi/build/binutils-gdb/gdb/testsuite/outputs/gdb.threads/dlopen-libpthread/dlopen-libpthread.so.d/libc.so.6 (0x00007f0a5cf03000)^M
>              /lib64/ld-linux-x86-64.so.2 (0x00007f0a5d132000)^M
> 
> This directory is created by build_executable_own_libs in
> lib/prelink-support.exp (used by the test).
> 
> Tweaking the regexp to include a forward slash makes it work for me:
> 

Hi Simon,

thanks for letting me know, and sorry for this ongoing annoyance.

I tested it this morning on three data points (openSUSE Leap 15.4, 
Ubuntu 22.04 with and without LD_PRELOAD=), and all looked fine.

But after you mentioned the FAIL, I did a clean build from trunk and 
managed to reproduce it.  I'm not sure what went wrong, either I tested 
the wrong test-case or I tested a different version of the patch.

Anyway, your suggestion fixes the FAIL for me as well.

I'll commit this asap.

Thanks,
- Tom

>    diff --git a/gdb/testsuite/gdb.threads/dlopen-libpthread.exp b/gdb/testsuite/gdb.threads/dlopen-libpthread.exp
>    index 134265ff470..c97e0284475 100644
>    --- a/gdb/testsuite/gdb.threads/dlopen-libpthread.exp
>    +++ b/gdb/testsuite/gdb.threads/dlopen-libpthread.exp
>    @@ -68,14 +68,14 @@ if { !$have_probe } {
>     # due to LD_PRELOAD.
>     set libpthread_maybe_preloaded 0
>     set binfile [standard_output_file $executable]
>    -if { [has_dependency $binfile libpthread\\.so] == 1 } {
>    +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_lib libpthread\\.so] == 0 } {
>    +if { [has_dependency $binfile_lib /libpthread\\.so] == 0 } {
>         set libpthread_missing 1
>     }
> 
> Simon