This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v5] Add pretty printers for the NPTL lock types
- From: Roland McGrath <roland at hack dot frob dot com>
- To: Martin Galvan <martin dot galvan at tallertechnologies dot com>
- Cc: libc-alpha at sourceware dot org, Daniel Gutson <daniel dot gutson at tallertechnologies dot com>, "Carlos O'Donell" <carlos at redhat dot com>, Siddhesh Poyarekar <sid at reserved-bit dot com>, Tom Tromey <tom at tromey dot com>
- Date: Mon, 11 Apr 2016 15:16:56 -0700 (PDT)
- Subject: Re: [PATCH v5] Add pretty printers for the NPTL lock types
- Authentication-results: sourceware.org; auth=none
- References: <1460405322-31278-1-git-send-email-martin dot galvan at tallertechnologies dot com> <20160411203830 dot EF45B2C3B22 at topped-with-meat dot com> <CAOKbPbYmtfq=qReDNhTkVgt64cSbsd=+VQ+rHAgigdfbhBdMcQ at mail dot gmail dot com> <20160411213057 dot 92EE82C3B22 at topped-with-meat dot com> <CAOKbPbausROA=TM1K8Up=ttc9sHxaLtBWUsi7KPxDiS77+Jiig at mail dot gmail dot com>
> I thought Depend took care of that.
Only in the wrongest possible way.
> In any case, Sid remarked that It would be clumsy to have the printers in
> different module directories now and then putting them all into the same
> directory during installation.
It's no different from header files and libraries, which all go into the
same installation directories.
> It also makes sense to have them tested separately through a single
> Makefile, and it's the right place to put things like test_common.py and
> the pretty printers README.
You can certainly have some common infrastructure code for both the
pretty-printer implementations and for their tests. It might well be fine
to have a subdir for that common infrastructure code. But anything
actually related to a particular type must reside in the subdir responsible
for the definition of that type.
> It's a technical issue, actually, and it's explained in all the test
> programs. Basically, I saw that having 'if' conditions split in more
> than one line seems to confuse gdb to the point where we need to issue
> a (somewhat random) number of 'next' commands to advance. This
> complicates testing quite a bit.
This suggests to me that the testing methodology is a poor choice. I'd
have to review what you've done in more detail to know what I think is the
best approach. I suspect that using "next" (or "step", etc.) in tests like
this is just a bad idea altogether (as opposed to only using explicit
breakpoints). If it turns out that using "next" over an "if" is an
important thing to be able to do, then put the complex condition into an
inline or macro.
> Ok. Is it ok if I place a single line of comment above the license,
> then leave a more detailed explanation below it? E.g. for
> nptl-printers.py we'd have:
>
> # Pretty printers for the NPTL lock types.
> # Copyright (C) 2016 Free Software Foundation, Inc.
That is exactly what we require.
The top comment should usually be only one line.
Thanks,
Roland