This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH v8] Add pretty printers for the NPTL lock types
- From: Siddhesh Poyarekar <siddhesh at sourceware dot org>
- To: Martin Galvan <martin dot galvan at tallertechnologies dot com>
- Cc: libc-alpha at sourceware dot org, Carlos O'Donell <carlos at redhat dot com>
- Date: Sun, 19 Jun 2016 22:14:52 +0530
- Subject: Re: [PATCH v8] Add pretty printers for the NPTL lock types
- Authentication-results: sourceware.org; auth=none
- References: <20160608153304 dot 12910-1-martin dot galvan at tallertechnologies dot com> <20160608153841 dot GA8366 at devel dot intra dot reserved-bit dot com> <CAOKbPbZCbrfM=FRq6e7C3c8uXp9v+BODAoh6Qat7XRwOb5cEHA at mail dot gmail dot com>
On Wed, Jun 15, 2016 at 12:14:30PM -0300, Martin Galvan wrote:
> Hi Sid, have you got any news on this? Could you test it?
Sorry this has taken so long, especially because I have not committed
the patch yet because I ran into a few issues while testing the patch.
When you run the binary under gdb for testing, you're not loading the
libc.so and friends that you just built, you're loading them from the
system. This is because our testsuite builds the binaries using
rpath-link and not rpath by default and one needs to take extra effort
to make sure that the correct libraries are picked during execution,
like using the testrun.sh or invoking the built ld.so directly.
Neither of those are feasible for running under gdb and doing a clean
enough debug session. The best option hence is to use rpath instead,
which guarantees that the desired libraries will be built.
However, when you actually do set everything up correctly (i.e. use
--enable-hardcoded-path-in-tests during configure), test-mutex-printer
still fails for me. I initially thought that it could be due to
thread debugging not being available and added an auto-load safe path
to the nptl_db directory, but that is probably not it because it does
finish successfully if I do something as trivial as printing
gdb.after. There is probably a race in that test that I haven't
looked at deeply enough to understand so that's something for you to
look at.
That brings me to the final point: debugging of tests when they fail.
There needs to be some more information printed on stdout so that one
may easily find out which part of the test failed by looking at the
${testname}.test-result file.
Now back to the main issue of rpath vs rpath-link. It is clear that
the pretty printer tests will always need rpath, so I would suggest
fixing that in the makefile instead of bailing out by documenting that
requirement (of enabling hardcoded path in tests during configure) in
the README.
Also, please revert to generating the constants file in objpfx and not
in the source tree in line with Joseph's clarification of practices in
glibc.
Siddhesh