This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH] Add pretty printers for the NPTL lock types
- From: Joseph Myers <joseph at codesourcery dot com>
- To: Martin Galvan <martin dot galvan at tallertechnologies dot com>
- Cc: <libc-alpha at sourceware dot org>, <tom at tromey dot com>, <carlos at redhat dot com>, <triegel at redhat dot com>, <palves at redhat dot com>, <vapier at gentoo dot org>, <daniel dot gutson at tallertechnologies dot com>
- Date: Fri, 15 May 2015 20:54:09 +0000
- Subject: Re: [PATCH] Add pretty printers for the NPTL lock types
- Authentication-results: sourceware.org; auth=none
- References: <1431716828-12854-1-git-send-email-martin dot galvan at tallertechnologies dot com>
On Fri, 15 May 2015, Martin Galvan wrote:
> +# Value of __mutex for shared condvars.
> +PTHREAD_COND_SHARED = ~ctypes.c_long(0).value
> +
> +# Value of __total_seq for destroyed condvars.
> +PTHREAD_COND_DESTROYED = ctypes.c_ulonglong(-1).value
Another issue: ctypes relates, I presume, to the types used by the
compiler used to compile Python. But what you want here is the types used
in glibc by the program being debugged, which may be different, both
because of cross-debugging, and because a native 64-bit GDB may debug both
32-bit and 64-bit inferiors.
That is, you can't compute these using ctypes; they have to be computed
using the types for the current inferior. I don't know enough about the
GDB Python interfaces to know whether what you have elsewhere in this
patch
> +PTHREAD_MUTEX_INCONSISTENT = gdb.parse_and_eval('~0u >> 1')
is safe (whether this Python code will be loaded separately for 32-bit and
64-bit inferiors and that evaluation, taking place when this module is
loaded, will use the correct type sizes for the inferior in question).
If it is safe, I'd expect it to be possible to use the same approach for
PTHREAD_COND_*. (Of course, if you're relying on a value like this that
isn't a constant defined in and extracted from a header, the relevant
glibc code needs a comment to point out this dependency. Or, better,
define the value as a macro in an internal header, use that macro where
glibc depends on the value, and extract from the internal header for
Python use.)
--
Joseph S. Myers
joseph@codesourcery.com