Questions about failing testcase nptl/test-mutex-printers

[Stefan Liebler <stli at linux dot vnet dot ibm dot com>]

Hi,

I'm running the testcase nptl/test-mutex-printers with all the needed 
prerequirements (build with debug-info, python-pexpect, gdb, ...).

The test passes if I start it without lock-elision.
If I run it with lock-elision (export 
GLIBC_TUNABLES=glibc.elision.enable=1) on s390x,
it fails with:
Error: Response does not match the expected pattern.
Command: print *mutex
Expected pattern: pthread_mutex_t
Response:  No symbol "mutex" in current context.
(gdb)


The program built with test-mutex-printers.c is started in gdb via 
test-mutex-printers.py.

But you don't need the script to reproduce the issue.
Just start the test-binary with gdb:
-gdb --args nptl/test-mutex-printers --direct
-(gdb) set environment GLIBC_TUNABLES glibc.elision.enable=1
-(gdb) b 79
 (gdb) r
Now we break at line 79:"      && pthread_mutex_lock (mutex) == 0 /* 
Test status (non-robust).  */"
just before the call of pthread_mutex_lock().
-"next" shows us the real issue:
(gdb) n

Program received signal SIGILL, Illegal instruction.
0x000003fffdf14f1c in __lll_lock_elision (futex=0x3ffffffe9b0,
    adapt_count=0x3ffffffe9c6, private=0)
    at ../sysdeps/unix/sysv/linux/s390/elision-lock.c:59

(gdb) disassemble
Dump of assembler code for function __lll_lock_elision:
...
   0x000003fffdf14f12 <+170>:	tbegin	0,65294
   0x000003fffdf14f18 <+176>:	jne	0x3fffdf14f24 <__lll_lock_elision+188>
=> 0x000003fffdf14f1c <+180>:	lhi	%r0,0
   0x000003fffdf14f20 <+184>:	j	0x3fffdf14f66 <__lll_lock_elision+254>
...

-Note: If we are now following the commands in test-mutex-printers.py 
script, we get the same response:
(gdb) print *mutex
No symbol "mutex" in current context.


I'm currently using GNU gdb (GDB) Fedora 8.0.1-30.fc27.
And yes, this is definitively a bug in gdb.

As I don't have access to other lock-elision enabled machines,
can somebody test this on power / intel?
What is the behaviour if you step over pthread_mutex_lock() with "next" 
if lock-elision is enabled?
Does the transaction abort and we are debugging the fallback-path 
(without a transaction) or does it stop just after pthread_mutex_unlock()?

If I step manually to the tbegin-instruction (which starts the 
transaction on s390x) and step over it, then gdb steps over the whole 
transaction and we are just after the tend-instruction.

Does it make sense to disable lock-elision for the pretty-printer-tests?
E.g. with the following patch:
diff --git a/scripts/test_printers_common.py 
b/scripts/test_printers_common.py
index 73ca525556..d74a8b4d4b 100644
--- a/scripts/test_printers_common.py
+++ b/scripts/test_printers_common.py
@@ -171,6 +171,9 @@ def init_test(test_bin, printer_files, printer_names):
     # Finally, load the test binary.
     test('file {0}'.format(test_bin))

+    # Disable lock elision.
+    test('set environment GLIBC_TUNABLES glibc.elision.enable=0')
+
 def go_to_main():
     """Executes a gdb 'start' command, which takes us to main."""


Bye.
Stefan