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:

> These printers are architecture-independent. However, most of the C macros
> defined in nptl/pthread.h and nptl/pthreadP.h had to be replicated in the Python
> code as global variables as there was no other way to check which flags were
> set.

I think we must eliminate this duplication before this patch can go in.  
That is, set up some mechanism for the values to be extracted at build / 
install time.  In addition, whenever this depends on some aspect of NPTL 
internals, there need to be comments on the relevant internals (e.g. 
structure field definitions) explaining how this code depends on them and 
so needs updating for any change.  Similarly, if this code is meant to 
handle all values in an enumeration / all flags from some set of flags, 
there needs to be a comment on that enumeration / set of flags drawing 
attention to the need to update this code when new values are added.

See the existing gen-as-const support for how compile-time values can get 
extracted for use in other contexts (there, values such as structure 
offsets get extracted for #defines for use in .S files, but much the same 
approach could extract header constants for use in Python code - though 
watch out for any signedness issues).  It's also possible to test-compile 
a sequence of programs to determine the value and type of an integer 
constant expression using the compiler.

(I have not otherwise reviewed this patch.)

-- 
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]