This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [RFC v2] Pretty printers for NPTL lock types
- From: Martin Galvan <martin dot galvan at tallertechnologies dot com>
- To: Joseph Myers <joseph at codesourcery dot com>
- Cc: "Carlos O'Donell" <carlos at redhat dot com>, libc-alpha at sourceware dot org, Daniel Gutson <daniel dot gutson at tallertechnologies dot com>, Torvald Riegel <triegel at redhat dot com>, Pedro Alves <palves at redhat dot com>
- Date: Thu, 12 Mar 2015 15:14:35 -0300
- Subject: Re: [RFC v2] Pretty printers for NPTL lock types
- Authentication-results: sourceware.org; auth=none
- References: <CAOKbPbZ+pWcouv2-VqnjVkNbbrA_7BieOmXv9fSofYU3kFjidQ at mail dot gmail dot com> <alpine dot DEB dot 2 dot 10 dot 1503121803360 dot 21400 at digraph dot polyomino dot org dot uk>
On Thu, Mar 12, 2015 at 3:07 PM, Joseph Myers <joseph@codesourcery.com> 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
entries).
> 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!