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: Joseph Myers <joseph at codesourcery dot com>
- To: Martin Galvan <martin dot galvan at tallertechnologies dot com>
- Cc: Siddhesh Poyarekar <sid at reserved-bit dot com>, <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 17:48:51 +0000
- 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> <CAOKbPbYPtn5mMpwGGD-HccXnhNz+eymiJ7Xwe_4WOnesYkw5=A at mail dot gmail dot com>
On Tue, 9 Feb 2016, Martin Galvan wrote:
> 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
See Roland's original comments resulting in test-wrapper-env as a separate
variable <https://sourceware.org/ml/libc-alpha/2012-10/msg00631.html>.
1. Work out where you want to run GDB when testing this feature - on the
system on which glibc is built (possibly a cross GDB), or on the system on
which glibc runs.
2. Work out what makefile variables are needed to describe how to run GDB
when testing this feature.
> 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.
Yes, there is a good argument that the right way to test this feature when
cross-building glibc is to use a cross-GDB (which may well still need new
makefile variables to describe how to run the cross-GDB on the system
running "make check" and the native gdbserver on the system running the
newly built glibc).
--
Joseph S. Myers
joseph@codesourcery.com