This is the mail archive of the libc-alpha@sourceware.org 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: [PATCH v8] Add pretty printers for the NPTL lock types


On Sun, Jun 19, 2016 at 1:44 PM, Siddhesh Poyarekar
<siddhesh@sourceware.org> wrote:
> 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.

Thanks for the answer. Can you specify what exactly is it that I'd
need to do to get this running properly? That is, please tell me,
step-by-step, exactly what I need to do in gdb/the Makefiles. I know
very little of this, and won't sink countless more hours dwelling
within the build system just to get it wrong again.

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

Odd. Will take a look at it. I doubt it's a race condition since I
specifically wrote it so that there wouldn't be any, but you never
know.

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

I don't know if Python's print() will end up in .test-result, but
yeah, that's definitely something necessary. At least if I can't
reproduce the failure I can send the new tests to you and we'll be
able to figure it out from the output.

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

See the first answer.

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

Sure. Hopefully nobody else will jump in and tell me to revert any
additional changes at the last minute :)


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