From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94371 invoked by alias); 27 Nov 2017 17:33:31 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Received: (qmail 94297 invoked by uid 89); 27 Nov 2017 17:33:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-9.7 required=5.0 tests=BAYES_00,GIT_PATCH_2,GIT_PATCH_3,KB_WAM_FROM_NAME_SINGLEWORD,LIKELY_SPAM_BODY,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 27 Nov 2017 17:33:28 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 059AF5AFC4 for ; Mon, 27 Nov 2017 17:33:27 +0000 (UTC) Received: from [127.0.0.1] (ovpn04.gateway.prod.ext.ams2.redhat.com [10.39.146.4]) by smtp.corp.redhat.com (Postfix) with ESMTP id 677065D9C6 for ; Mon, 27 Nov 2017 17:33:26 +0000 (UTC) Subject: Re: [PATCH v2 0/3] C++ debugging improvements: wild matching and ABI tags To: gdb-patches@sourceware.org References: <1511802824-643-1-git-send-email-palves@redhat.com> From: Pedro Alves Message-ID: Date: Mon, 27 Nov 2017 17:33:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.4.0 MIME-Version: 1.0 In-Reply-To: <1511802824-643-1-git-send-email-palves@redhat.com> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-SW-Source: 2017-11/txt/msg00694.txt.bz2 And as usual, I forgot to mention that I also pushed this to the: users/palves/cxx-breakpoint-improvements-v2 branch. Thanks, Pedro Alves On 11/27/2017 05:13 PM, Pedro Alves wrote: > Here's v2 of the series originally posted here: > > [PATCH 00/40] C++ debugging improvements: breakpoints, TAB completion, more > https://sourceware.org/ml/gdb-patches/2017-06/msg00012.html > > Most of the series is in, except that bits that I was really > originally after. :-) > > What remains is: > > - teaching GDB to set breakpoints on all namespaces/classes/scopes by > default, along with a new option "break -qualified" to override the > behavior. > - fix setting breakpoints on symbols with [abi:cxx11] tags. > > In this version I've addressed Keith's comments, and implemented his > suggestion of making "-qualified" work with linespecs too, instead of > just with explicit locations: > https://sourceware.org/ml/gdb-patches/2017-11/msg00618.html > > In v1, tests and documentation changes were in separate patches, but > since now we're down to only two distinct improvements, I've moved > tests and docs changes to the patches that actually implements each > feature. The documentation for the ABI tags patch (patch #3) has not > changed since the previous version, and was already reviewed and > approved. The documentation for the wild matching feature was changed > since the last revision, so may benefit from review again. > > Blurb from v1 with already-merged bits stripped follows: > > A few months back I was looking at making GDB use gnulib's C++ > namespace mode, because the default mode has gnulib define its > replacements using macros, like "#define open rpl_open". In C++ > that's a bad idea, given that using names like "open", "close", > etc. in classes and namespaces is the natural thing to do. E.g., > "struct target_ops::to_open" could be "class target::open". > > After experimentation, I concluded that the best would be to wrap all > of GDB in: > > namespace gdb { > } > > and so I tried it: > https://github.com/palves/gdb/commits/palves/cxx-gdb-namespace > > however, when I actually got it working and started debugging that > GDB, I immediately got frustrated with GDB's C++ support. I.e., the > dog food didn't taste so good. > > The problem was that now you'd always need to prefix every function > name with "gdb::". I.e., "b gdb::internal_error", etc., etc. And it > gets annoying pretty fast. > > I thought that GDB should be able to do better. I thought that maybe > GDB could infer the namespace from local context, so you'd still be > able to do "b foo", and that would find "gdb::foo". However, that > doesn't work well, because you want to be able to conveniently set > breakpoints before starting a program, when there's no frame yet. > And, running to main doesn't help, because main is not in any > namespace. Also, the direction linespecs / setting breakpoints is > aiming, is in not relying in local context at all. Instead, match the > most possible, and let users filter it down if they want. I.e., e.g., > "b foo" sets locations in all "foo" functions in the program in all > compilation units, no matter whether they're both extern or static > function, no matter where you're currently stopped in the program. > Likewise "b source.c:foo" looks at all source files named "source.c", > not just the current source if it happens to have that name. You can > set set a breakpoint on a C++ symbol named "some_klass::method()", > even if the current frame's language is C, not C++. Etc., etc. > > The idea then occurred to me. How about we make GDB ignore leading > namespaces when setting breakpoints? I.e., just like "b foo" sets a > breakpoint on all "foo"s in the program, and you can zoom in on > specific "foo" functions by specifying a source file to scope the > symbol search, like "b source.c:foo", by default we'd make "b foo" set > a breakpoint on all functions and methods named "foo" too, like > "A::foo", "B::A::foo", "(anonymous namespace)::foo", and of course > global "foo". And then if you scope the name, like "A::foo", GDB > would find both "A::foo", and "B::A::foo", but not the others. Etc., > etc. E.g.,: > > (gdb) b function[TAB] > A::function() > B::A::function() > function() > (anonymous namespace)::function() > (gdb) b function > Breakpoint 1 at 0x4005ce: function. (4 locations) > > (gdb) b A::function[TAB] > A::function() > B::A::function() > (gdb) b function > Breakpoint 1 at 0x4005ce: function. (2 locations) > > That sounded quite promising to me. Turns out that that's what lldb > does too, so I started experimenting with doing the same in GDB. > Along the way, I realized that gdb's Ada support has always behaved > like that... ada-lang.c calls it "wild matching" vs "full matching" > (see full_match and wild_match). So it's not really a new idea for > GDB. The problem is that Ada does that on its own little ada-lang.c > corner, out of view.. > > Actually, above I'm showing TAB completion. But there's more to that. > Once it got it working for setting breakpoints, I realized that TAB > completion would need to be adjusted too. TAB completion goes via > different symbol search code paths... I required adjustment because > while "b foo[RET]" would find all functions named "foo", "b foo[TAB]" > would only show symbols that start with "foo"... > > Fixing that required virtually rewriting how GDB interacts with > readline for completion. Most of that rework is already in master, > but one issue is not addressed yet, which is that you want this to > happen: > > (gdb) b func[TAB] # expands input line to ... > (gdb) b function( # ... this > (gdb) b function([TAB] # another tab now shows you the candidates > A::B::function(int) > A::C::function(long) > > Notice how the input line above was expanded to "function(", but, > that's not actually the common leading prefix between all completion > candidates! If we'd let readline compute what it calls the "lowest > common denominator", then this is what you'd see: > > (gdb) b func[TAB] # expands input line to ... > (gdb) b A:: # ... this... > > which is obviously bogus. > > And then on top of the above, the series fixes setting breakpoints on > symbols with [abi:cxx11] tags. > > Pedro Alves (3): > Handle custom completion match prefix / LCD > Make "break foo" find "A::foo", A::B::foo", etc. [C++ and wild > matching] > Breakpoints in symbols with ABI tags (PR c++/19436) > > gdb/doc/gdb.texinfo | 86 +++++- > gdb/NEWS | 42 +++ > gdb/ada-lang.c | 22 +- > gdb/ax-gdb.c | 3 +- > gdb/breakpoint.c | 32 ++- > gdb/c-lang.c | 2 +- > gdb/completer.c | 61 +++- > gdb/completer.h | 139 ++++++++- > gdb/cp-support.c | 218 +++++++++++++- > gdb/cp-support.h | 7 + > gdb/dwarf2read.c | 48 ++++ > gdb/guile/scm-breakpoint.c | 6 +- > gdb/language.c | 11 +- > gdb/language.h | 3 +- > gdb/linespec.c | 52 +++- > gdb/linespec.h | 12 +- > gdb/location.c | 95 +++++-- > gdb/location.h | 38 ++- > gdb/mi/mi-cmd-break.c | 3 +- > gdb/python/py-breakpoint.c | 3 +- > gdb/python/python.c | 3 +- > gdb/symtab.c | 11 +- > gdb/symtab.h | 20 +- > gdb/testsuite/gdb.base/langs.exp | 2 +- > gdb/testsuite/gdb.cp/meth-typedefs.exp | 39 ++- > gdb/testsuite/gdb.cp/namespace.exp | 2 +- > gdb/testsuite/gdb.linespec/cpcompletion.exp | 423 ++++++++++++++++++++++++++++ > gdb/testsuite/gdb.linespec/cpls-abi-tag.cc | 93 ++++++ > gdb/testsuite/gdb.linespec/cpls-abi-tag.exp | 286 +++++++++++++++++++ > gdb/testsuite/gdb.linespec/explicit.exp | 80 +++--- > gdb/testsuite/lib/completion-support.exp | 2 +- > gdb/utils.c | 96 ++++++- > gdb/utils.h | 16 +- > 33 files changed, 1782 insertions(+), 174 deletions(-) > create mode 100644 gdb/testsuite/gdb.linespec/cpls-abi-tag.cc > create mode 100644 gdb/testsuite/gdb.linespec/cpls-abi-tag.exp >