public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Bruno Larsen <blarsen@redhat.com>
To: Tom Tromey <tom@tromey.com>,
	Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [RFC PATCH] [gdb] Fix std::unique_ptr printing regression (PR 28480)
Date: Thu, 4 Nov 2021 16:10:13 -0300	[thread overview]
Message-ID: <4e363cd6-5491-2570-788c-ae2adde3dfe4@redhat.com> (raw)
In-Reply-To: <874k8rkbf9.fsf@tromey.com>

On 11/4/21 15:44, Tom Tromey wrote:
>>>>>> "Bruno" == Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org> writes:
> 
> Thank you for the patch.
> 

Thanks for reviewing!

> Bruno> Or with a valid memory address. This happened because the searching
> Bruno> algorithm, when looking for internal members of __uniq_ptr, would stop
> Bruno> at the first _M_head_impl, which is of type class Deleter, instead of
> Bruno> returning the second finding, which is the managed pointer.
> 
> I don't really understand this explanation.
> However, see my comments below about the test case.

Further conversation on bugzilla revealed that I didn't either. Here's a better one: the ambiguity detection was failing on this case, because unique_ptr was using [[no_unique_address]], and the original patch depends on different boffsets to determine if a query is ambiguous.

> 
> Bruno> The second is that I'm having trouble with the testing. running with
> Bruno> -data-directory gdb/data-directory gives me a very verbose printing that
> Bruno> is always correct, but also counter-productive for debugging. How can I
> Bruno> make the testsuite have the minimal printing?
> 
> Bruno> +  std::unique_ptr<int> uptr(nullptr);
> 
> Using a standard library type in the test suite is usually not what you
> want, because it means that the gdb feature being tested then depends on
> the precise implementation of this type.
> 
> Instead, because you're changing gdb to handle some C++ scenario, I
> think it would be better to write out exactly what is being tested --
> basically, the relevant parts of unique_ptr.  I think it's fine to add
> these to the existing test.

Jwakely came up with a better, self contained test, which is in the bugzilla report.

> 
> However, it sounds like you also are trying to test the pretty-printer
> here?  This part wasn't clear to me, but IIRC std::unique_ptr has a
> pretty-printer in libstdc++.  In this case, you'd also need to write a
> pretty-printer, in which case you'd probably just want a whole new test
> in gdb.python.> 
> Integration testing for the unique_ptr pretty-printer would also be
> good, but those tests ought to be in libstdc++.
> 
> I don't have a comment on the particular change here.  I suspect it
> ought to be done some other way, but I don't really understand it.  I
> think a more self-contained test would help with this as well.

Right. The specific case I was testing did come from libstdc++'s pretty printer, but it ended up showing an ambiguous case not covered by the original patch, and this change would mask the problem, instead of fixing it. A proper patch will be comming soon

> 
> thanks,
> Tom
> 


-- 
Cheers!
Bruno Larsen


      reply	other threads:[~2021-11-04 19:10 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-11-04 15:13 Bruno Larsen
2021-11-04 18:44 ` Tom Tromey
2021-11-04 19:10   ` Bruno Larsen [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4e363cd6-5491-2570-788c-ae2adde3dfe4@redhat.com \
    --to=blarsen@redhat.com \
    --cc=gdb-patches@sourceware.org \
    --cc=tom@tromey.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).