This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PING][PATCH v3] Add pretty printers for the NPTL lock types
- From: Torvald Riegel <triegel at redhat dot com>
- To: Martin Galvan <martin dot galvan at tallertechnologies dot com>
- Cc: libc-alpha at sourceware dot org, Tom Tromey <tom at tromey dot com>, "Carlos O'Donell" <carlos at redhat dot com>, Pedro Alves <palves at redhat dot com>, vapier at gentoo dot org, Daniel Gutson <daniel dot gutson at tallertechnologies dot com>
- Date: Tue, 24 Nov 2015 18:55:48 +0100
- Subject: Re: [PING][PATCH v3] Add pretty printers for the NPTL lock types
- Authentication-results: sourceware.org; auth=none
- References: <1447451408-3050-1-git-send-email-martin dot galvan at tallertechnologies dot com> <1447871395 dot 25500 dot 81 dot camel at localhost dot localdomain> <CAOKbPbajtscrEL53RPMB-YkLgUYzb01_EAS0nABqEUaspi2j2Q at mail dot gmail dot com> <1447977835 dot 25500 dot 119 dot camel at localhost dot localdomain> <CAOKbPbZmzaQkQdK8Bnh23uawVypjaje_o1og9rc4zoVU_mKZog at mail dot gmail dot com>
On Fri, 2015-11-20 at 10:42 -0300, Martin Galvan wrote:
> On Thu, Nov 19, 2015 at 9:03 PM, Torvald Riegel <triegel@redhat.com> wrote:
> > I have no concrete suggestions right now. Is there a stub that could be
> > used to avoid having to test through gdb?
>
> By "stub" do you mean a C code snippet, like the other tests? I do
> have a few programs that play out different use cases; but I don't see
> how we could test the printers without running gdb.
I mean as a replacement for gdb, something like a small piece of code
that can pretend to be gdb and call the pretty printers. Maybe stub is
the wrong word; I was thinking about something like a unit test thingy.
But I don't know whether that would actually be small, or whether it
would be easier to just test through gdb.
> > There's still a question of how and where that implementation knowledge
> > is encapsulated. For example, glibc could potentially provide pretty
> > printers by itself close to the actual implementation, or have more
> > helper functions that serve as getters for the attributes you test (eg,
> > assuming that some flag is nonzero meaning that it's process-shared).
> > But I'm not sure whether we want to go to that way.
>
> Indeed. The purpose of this particular contribution is to provide a
> tool for the user, not to change the code of glibc itself.
But it is related to glibc's code, obviously. The maintenance problem
is there even if we declare it a tool for the user.