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: [PATCH] Add pretty printers for the NPTL lock types


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


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