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: Siddhesh Poyarekar <sid at reserved-bit dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: Martin Galvan <martin dot galvan at tallertechnologies dot com>, libc-alpha at sourceware dot org, Daniel Gutson <daniel dot gutson at tallertechnologies dot com>, Carlos O'Donell <carlos at redhat dot com>, Tom Tromey <tom at tromey dot com>
- Date: Tue, 12 Apr 2016 08:33:25 +0530
- 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> <20160411221656 dot 65CB82C3B38 at topped-with-meat dot com>
On Mon, Apr 11, 2016 at 03:16:56PM -0700, Roland McGrath wrote:
> 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.
So you're only suggesting moving nptl-printers.py to nptl, which seems
fine given that it is specific to nptl. That does not conflict with
my insistence to have a subdir for pretty-printers because my
intention was to make it the destination for common code. I did not
pay attention to what *should't* go into pretty-printers, which I now
realize I should have.
> 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.
Actually the comments on those lines are quite inane and could be
dropped altogether, which should take care of most of those long
lines.
Siddhesh