This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PING 3][PATCH v10] Add pretty printers for the NPTL lock types
- From: Martin Galvan <martin dot galvan at tallertechnologies dot com>
- To: libc-alpha at sourceware dot org, "Carlos O'Donell" <carlos at redhat dot com>, Siddhesh Poyarekar <sid at reserved-bit dot com>, Pedro Alves <palves at redhat dot com>, Stefan Liebler <stli at linux dot vnet dot ibm dot com>
- Date: Wed, 3 Aug 2016 13:06:47 -0300
- Subject: Re: [PING 3][PATCH v10] Add pretty printers for the NPTL lock types
- Authentication-results: sourceware.org; auth=none
- References: <20160803143224.2549-1-martin.galvan@tallertechnologies.com> <CAOKbPbZfe0fc=vtKM3gDxq21V2Ef9atdhEOobA5pcfx2Ta2cag@mail.gmail.com>
On Wed, Aug 3, 2016 at 12:13 PM, Martin Galvan
<martin.galvan@tallertechnologies.com> wrote:
>> If glibc is built on i686 fedora 23 with debug-info:
>> FAIL: nptl/test-condattr-printers; out-file:
>> Error: Response does not match the expected pattern.
>> Command: print *condvar
>> Expected pattern: Shared = Yes
>> Response: $6 = pthread_cond_t = {Threads waiting for this condvar = 0,
>>
>> Clock ID = CLOCK_REALTIME, Shared = No, Mutex = Cannot access memory at address 0xffffffff
I think I know what might be happening. Internally, glibc records the
'shared' attribute of a condvar within its '__mutex' member. If a
condvar isn't shared, __mutex points to its associated mutex;
otherwise it's set to ~0l. From your output, it seems that in your
32-bit machines it's being correctly set to 0xffffffff, which seems to
be different from the generated PTHREAD_COND_SHARED. Could you please
take a look at that value and see if it's different from __mutex? You
should be able to find it in the generated nptl_lock_constants.py. If
it's also 0xffffffff, we may need to print both values in
ConditionVariablePrinter.read_attributes and see why the comparison is
failing.
FWIW, I tested this on a (32-bit) ARM board and it always worked fine.
I don't have the board handy right now to check what the generated
value was, though.
On Wed, Aug 3, 2016 at 12:56 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> I don't see any changes to install.texi in this patch. The list of
> software version requirements in install.texi needs to be updated to state
> the GDB and PExpect version requirements for testing the pretty printers
> (and should be clear that GDB needs Python support for this and that
> PExpect needs to be for the Python version GDB was linked with, if that's
> the case, since distributions may well package it for both Python 2 and
> Python 3). The INSTALL file should then be regenerated from the updated
> install.texi.
I didn't know about this, thanks for pointing it out.