This is the mail archive of the 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: [RFC v2] Pretty printers for NPTL lock types

On Thu, Mar 12, 2015 at 3:07 PM, Joseph Myers <> wrote:
> New files should have copyright and license notices as usual with the
> usual glibc license (and a copyright assignment will be needed).

Thanks for your answer. As this is a RFC and not a proper patch yet, I
didn't think that was necessary for now (the same goes for changelog

> I don't like the duplication of large numbers of constants from the glibc
> headers.  I think you need a way to extract these constants from the
> headers at glibc build time, or otherwise to ensure that the two sets of
> definitions remain consistent.

As I said in my original e-mail, I don't like them either. I'm not
sure about extracting them at build time, since they're scattered all
over the code. Ideally gdb would be able to read their actual values,
but that would mean everyone would have to recompile their glibc with
debugging symbols. Even then I'm not sure if it would work.

>Are all these constants always
> architecture-independent, and independent of multilib for configurations
> supporting multiple ABI variants?

Yes, they seem to be arch-independent for the most part. One of the
constants is actually INT_MAX, but my Python script uses gdb to
calculate its value assuming we're on a 2's complement CPU.

>Also, comments would be needed at the
> definitions of the constants in the headers pointing out that the pretty
> printers should be updated when new constants are added to each relevant
> set of constants.

Agreed. Will add this on v3.

Thanks a lot for the feedback!

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