This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Questions about failing testcase nptl/test-mutex-printers


On 03/28/2018 03:15 PM, Carlos O'Donell wrote:
On 03/28/2018 06:58 AM, Stefan Liebler wrote:
Does it make sense to disable lock-elision for the pretty-printer-tests?

Yes it does, and that is probably the correct answer in this case.

Many of the tests rely on looking at the internal details of the lock,
particularly if you're going to pretty-print it, and elision does not allow
that to happen because the lock and any modifications are elided.

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

Someone would have to confirm on at least one other arch to make sure this works
as expected.


PING.
Is there anybody with an intel / power lock-elision machine who can test this?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]