[PATCH v8] Add pretty printers for the NPTL lock types

[Martin Galvan]

I've confirmed the test is failing because of a gdb bug:

https://sourceware.org/bugzilla/show_bug.cgi?id=20291

I'll be working on fixing that bug, but I don't think that should
block the merging of this patch. Right now I'm using set
scheduler-locking on to grab the child thread's ID for more rigurous
testing. We can either leave it as it is, knowing it's a gdb bug, or
remove the check for the child thread's ID (for now at least).

I'm still curious about info share showing the libraries were loaded
correctly (to me at least). Can you please tell me what are you
seeing?

(Also, I meant to type link-libc-tests-rpath-link = $(old-link-rpath)
in my last e-mail. Sorry about that).

On Tue, Jun 21, 2016 at 6:22 PM, Martin Galvan
<martin.galvan@tallertechnologies.com> wrote:
> On Mon, Jun 20, 2016 at 1:12 AM, Siddhesh Poyarekar
> <siddhesh@sourceware.org> wrote:
>> In Makeconfig there is a conditional that decides whether to use rpath
>> or rpath-link.  Additionally it also decides whether to use the built
>> dynamic linker or the system dynamic linker.  You'll have to enhance
>> the conditional so that it selects rpath and the built dynamic linker
>> when in the pretty-printers subdir.
>
> Great, how would I go about doing this? That is, just exactly what
> should I write? I'm thinking of adding something like
>
> old-link-rpath := link-libc-tests-rpath-link
> link-libc-tests-rpath-link = -Wl,-rpath=$(rpath-link)
>
> at the beginning of pretty-printers/Makefile, and then
>
> link-libc-tests-rpath-link = old-link-rpath
>
> at the end.
>
> In any case, how can I know gdb isn't loading the recently built
> libraries? info share shows the following for test-mutex-printer:
>
> (gdb) info share
> From                To                  Syms Read   Shared Object Library
> 0x00007ffff7ddbad0  0x00007ffff7df5960  Yes
> /home/martin/glibc/install/lib/ld-linux-x86-64.so.2
>                                         No          linux-vdso.so.1
> 0x00007ffff7bc3a90  0x00007ffff7bd03f1  Yes
> /home/martin/glibc/install/lib/libpthread.so.0
> 0x00007ffff78489a0  0x00007ffff796ad53  Yes
> /home/martin/glibc/install/lib/libc.so.6
>
> Looks to me like it's finding the built library alright.
>
> Just in case, I'm using gdb 7.7.1. However, gdb 7.11.50.20160531-git
> also seems to be loading fine:
>
> (gdb) info share
> From                To                  Syms Read   Shared Object Library
> 0x00007ffff7ddbad0  0x00007ffff7df5960  Yes
> /home/martin/glibc/install/lib/ld-linux-x86-64.so.2
> 0x00007ffff7bc3a90  0x00007ffff7bd03f1  Yes
> /home/martin/glibc/install/lib/libpthread.so.0
> 0x00007ffff78489a0  0x00007ffff796ad53  Yes
> /home/martin/glibc/install/lib/libc.so.6
>
>> Yes, it is not a bad idea to print out diagnostic information even in
>> case of success.  The hang (rather, timeout) happens on line 66
>> ('Owner ID': r'{0} \(dead\)') for me.
>
> Now, here's the interesting thing: it seems that set scheduler-locking
> on (which is supposed to prevent the child thread from running) isn't
> working correctly in gdb 7.11, yet it does in gdb 7.7. I'll look
> further into this and get back at you. In the meanwhile, it would be
> useful if you told me which version are you using.
>
> Thanks.