This is the mail archive of the mailing list for the glibc project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PING 2][PATCH v3] Add pretty printers for the NPTL lock types

On Fri, Feb 5, 2016 at 1:19 PM, Carlos O'Donell <> 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 <> 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

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
<> 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

> 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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]