This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PING 2][PATCH v3] Add pretty printers for the NPTL lock types
- From: Martin Galvan <martin dot galvan at tallertechnologies dot com>
- To: Siddhesh Poyarekar <sid at reserved-bit dot com>
- Cc: libc-alpha at sourceware dot org, Tom Tromey <tom at tromey dot com>, "Carlos O'Donell" <carlos at redhat dot com>, Torvald Riegel <triegel 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, 9 Feb 2016 14:40:31 -0300
- Subject: Re: [PING 2][PATCH v3] Add pretty printers for the NPTL lock types
- Authentication-results: sourceware.org; auth=none
- References: <1447768994-5368-1-git-send-email-martin dot galvan at tallertechnologies dot com> <20160209155450 dot GE1904 at devel dot intra dot reserved-bit dot com>
On Fri, Feb 5, 2016 at 1:19 PM, Carlos O'Donell <carlos@redhat.com> wrote:
> You need to:
>
> - Create a test script that is run as a test.
> - The test script needs to check for gdb, this can't
> be done at host configure time because the test script
> might be run on a remote host for cross-testing via the
> test wrapper.
> - If gdb is not present on the target then fail with
> UNSUPPORTED (not sure if this is possible, we usually
> mark unsupported testes by putting them into a special
> Make variable).
> - If gdb is present then run it with a script (-x) and
> do some printing tests of various initialized mutexes
> and a test program, and then compare that to expected
> data (store the expected data in a file if you want)
> and return PASS or FAIL.
I think it'd be way easier to just use PExpect in a single Python
script. I've been playing around with it and it seems to work fine,
and it uses a GPL-compatible license. I'll write a few test programs
with various kinds of lock types that exercise the pretty printers and
check for the output using PExpect.
On Fri, Feb 5, 2016 at 1:28 PM, Joseph Myers <joseph@codesourcery.com> wrote:
> Note that right now we don't have any test scripts that run on the glibc
> host, they all run on the build system. Thus, the makefile variables
> describing how to run programs for the glibc host, test-wrapper,
> test-wrapper-env and test-wrapper-env-only, all expect to be running a
> binary.
>
> The effect is that a new variable or variables needs adding. It might
> default to using existing variables, and that might be right when
> cross-testing via ssh - but people cross-testing using an emulator to run
> binaries (the same situation for which the default setting of
> test-wrapper-env may not work) might need to do something different.
I'm sorry, but I don't understand what you mean by this, as I'm not
very familiar with the glibc Makefile system. If you mean that the
pretty printers should be somehow tested in the glibc host instead of
the build system (assuming they're different), I don't see why we
should do that. If we're cross-debugging, the printers wouldn't run on
the glibc host but on the machine we're running the main gdb instance
on.
In any case, this sounds like even more complexity added to this
particular contribution.
On Tue, Feb 9, 2016 at 12:54 PM, Siddhesh Poyarekar
<sid@reserved-bit.com> wrote:
> These bits look generic, so I would suggest pulling them out into a
> separate file and make it reusable for other modules' pretty
> printers.
Those bits will be gone away in the next patch. I had to define my own
Printer classes because of a bug in the gdb API that wouldn't trigger
pretty printers for typedef'd variables. That bug was fixed a while
ago in the gdb mainline, so I'll stick to using
gdb.RegexpCollectionPrettyPrinter.
> In fact, I think the pretty printing code should go into a
> separate directory (gdb-pp or similar, maybe put the README file in
> this) so that all pretty printers stay in one place. It would be
> clumsy to have them in different module directories now and then
> putting them all into the same directory during installation. It
> would be much easier to test them with all of them in the same
> directory.
Ok.