This is the mail archive of the
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: Thu, 23 Jun 2016 22:10:06 +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> <20160619164448 dot GA5245 at devel dot intra dot reserved-bit dot com> <CAOKbPbYpRcwJ8QNSgvW9BxkOeTSBnWEGGFRMOY=RSzoK6k1-Bw at mail dot gmail dot com> <20160620041246 dot GB5245 at devel dot intra dot reserved-bit dot com> <CAOKbPbZknCcBGozK_v8SC=PyJdczwr7ss6Y1y1hs2x8ag7cpxA at mail dot gmail dot com>
On Tue, Jun 21, 2016 at 06:22:27PM -0300, Martin Galvan wrote:
> Great, how would I go about doing this? That is, just exactly what
> should I write? I'm thinking of adding something like
> old-link-rpath := link-libc-tests-rpath-link
> link-libc-tests-rpath-link = -Wl,-rpath=$(rpath-link)
> at the beginning of pretty-printers/Makefile, and then
> link-libc-tests-rpath-link = old-link-rpath
> at the end.
I was actually thinking of something even simpler, like setting
build-hardcoded-path-in-tests in Makeconfig if the subdir is
pretty-printers. You could over-engineer it by adding a new
test-need-hardcoded-path variable that each makefile sets and then
test that in Makeconfig, but I think we can leave that for when any
other subdir always needs a hardcoded path in tests.
> In any case, how can I know gdb isn't loading the recently built
> libraries? info share shows the following for test-mutex-printer:
> (gdb) info share
> From To Syms Read Shared Object Library
> 0x00007ffff7ddbad0 0x00007ffff7df5960 Yes
> No linux-vdso.so.1
> 0x00007ffff7bc3a90 0x00007ffff7bd03f1 Yes
> 0x00007ffff78489a0 0x00007ffff796ad53 Yes
> Looks to me like it's finding the built library alright.
I had checked /proc/PID/maps of the inferior. I can run it again over
the weekend and check what 'info shared' says if you want, but if
there's a difference, I'd say gdb is wrong and not the proc file.