[PATCH] [gdb/testsuite] Fix gdb.mi/mi-dlmopen.exp

[PATCH] [gdb/testsuite] Fix gdb.mi/mi-dlmopen.exp

[Tom de Vries]

On x86_64-linux (using glibc 2.40), in test-case gdb.mi/mi-dlmopen.exp we end
up with 3 instances of the dynamic loader /lib64/ld-linux-x86-64.so.2:
...
&"info sharedlibrary\n"
~"From                To                  Linker Syms Shared Object Library\n"
                                          NS     Read
~"0x00007ffff7fc8000  0x00007ffff7fff000  0      Yes  ...
  ...
~"0x00007ffff7fc8000  0x00007ffff7fff000  1      Yes  ...
  ...
~"0x00007ffff7fc8000  0x00007ffff7fff000  2      Yes  ...
...
and all 3 instances sharing the same mapping.

Two subsequent unload events:
...
=library-unloaded,
 id="/lib64/ld-linux-x86-64.so.2",
 target-name="/lib64/ld-linux-x86-64.so.2",
 host-name="/lib64/ld-linux-x86-64.so.2",
 thread-group="i1",
 ranges=[{from="0x00007ffff7fc8000",to="0x00007ffff7fff000"}],
 still-in-use="true"
=library-unloaded,
 id="/lib64/ld-linux-x86-64.so.2",
 target-name="/lib64/ld-linux-x86-64.so.2",
 host-name="/lib64/ld-linux-x86-64.so.2",
 thread-group="i1",
 ranges=[{from="0x00007ffff7fc8000",to="0x00007ffff7fff000"}],
 still-in-use="true"
...
report still-in-use as true.

And that's correct:
- after the first unload, the mapping is still in use by two instances
- after the second unload, the mapping is still in use by one instance

On ppc64le-linux (using glibc 2.34), I have instead for dynamic linker
/lib64/ld64.so.2:
...
&"info sharedlibrary\n"
~"From                To                  Linker Syms Shared Object Library\n"
                                          NS     Read
~"0x00007ffff7f80000  0x00007ffff8000000  0      Yes  ...
~"0x0000000000000160  0xffffffffffff0000  1      Yes  ...
~"0x0000000000000160  0xffffffffffff0000  2      Yes  ...
...
only 2 instances of the same mapping.

The mapping looks suspiciously large to me, perhaps this is a bug in glibc.
I didn't run into this problem with two other ppc64le-linux setups, with glibc
versions 2.40 and 2.38.  But I haven't tracked it down, so I can't rule out
the possibility that there's a gdb problem.

Regardless, the still-in-use values:
...
=library-unloaded,
 id="/lib64/ld64.so.2",
 target-name="/lib64/ld64.so.2",
 host-name="/lib64/ld64.so.2",
 thread-group="i1",
 ranges=[{from="0x0000000000000160",to="0xffffffffffff0000"}],
 still-in-use="true"
=library-unloaded,
 id="/lib64/ld64.so.2",
 target-name="/lib64/ld64.so.2",
 host-name="/lib64/ld64.so.2",
 thread-group="i1",
 ranges=[{from="0x0000000000000160",to="0xffffffffffff0000"}],
 still-in-use="false"
...
look as expected to me:
- after the first unload, the mapping is still in use by one instance
- after the second unload, the mapping is no longer in use

However, the test-case produces:
...
FAIL: gdb.mi/mi-dlmopen.exp: still-in-use fields were all correct
...
because it expects still-in-use == true for both unloads.

Fix this by distinguishing between the two cases:
- all mappings are the same: expect still-in-use == true
- otherwise: allowing either true or false for still-in-use.

For the second case, we could try to keep track of how many instances a range
has, and predict the precise value of still-in-use based on that, but I'm not
sure it's worth the effort for what looks like a corner-case.

Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=33662
---
 gdb/testsuite/gdb.mi/mi-dlmopen.exp | 28 +++++++++++++++++++++++++++-
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/gdb.mi/mi-dlmopen.exp b/gdb/testsuite/gdb.mi/mi-dlmopen.exp
index ff854ac7dd4..729a37eae28 100644
--- a/gdb/testsuite/gdb.mi/mi-dlmopen.exp
+++ b/gdb/testsuite/gdb.mi/mi-dlmopen.exp
@@ -162,6 +162,7 @@ proc check_solib_unload_events {} {
     # Check that the dynamic linker has now been loaded multiple times.
     set dyld_info [get_dyld_info]
     set dyld_count [lindex $dyld_info 0]
+    set dyld_start_addr [lindex $dyld_info 1]
     if { $dyld_count < 2 } {
 	unsupported "not enough instances of the dynamic linker are mapped in"
 	return
@@ -185,7 +186,32 @@ proc check_solib_unload_events {} {
 	    if {[is_dyln $lib]} {
 		# This is the dynamic linker being unloaded.
 		incr dyld_unload_count
-		set expected_in_use "true"
+
+		if {$dyld_start_addr != ""} {
+		    # In this case (x86_64-linux, glibc 2.40):
+		    #   From                To                  Linker NS
+		    #   0x00007ffff7fc8000  0x00007ffff7fff000  0
+		    #   0x00007ffff7fc8000  0x00007ffff7fff000  1
+		    #   0x00007ffff7fc8000  0x00007ffff7fff000  2
+		    # the three instances are mapped at the same position, and
+		    # after two unloads the mapping is still in use, so we
+		    # expect true for both unloads.
+		    set expected_in_use true
+		} else {
+		    # And in this case (ppc64le-linux, glibc 2.34):
+		    #   From                To                  Linker NS
+		    #   0x00007ffff7f80000  0x00007ffff8000000  0
+		    #   0x0000000000000160  0xffffffffffff0000  1
+		    #   0x0000000000000160  0xffffffffffff0000  2
+		    # two instances are mapped at the same position, and after
+		    # the first unload it's still in use, but not after the
+		    # second one.
+		    # We could add instances per mapping tracking to predict
+		    # still-in-use for each unload, but it doesn't seem to be
+		    # worth the trouble for this cornercase.  So just accept
+		    # whatever value was produced.
+		    set expected_in_use $in_use
+		}
 	    } else {
 		set expected_in_use "false"
 	    }

base-commit: cd02e2a209482dd9fa06945ffec0675da7dfd74e
-- 
2.51.0