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