[PATCH v2 0/3] C++ debugging improvements: wild matching and ABI tags
Pedro Alves
palves@redhat.com
Mon Nov 27 17:33:00 GMT 2017
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
>
More information about the Gdb-patches
mailing list