This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: GDB hooks for debugging GCC
- From: David Malcolm <dmalcolm at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 26 Aug 2013 14:48:57 -0400
- Subject: Re: GDB hooks for debugging GCC
- Authentication-results: sourceware.org; auth=none
- References: <1375494523 dot 4994 dot 108 dot camel at surprise> <52127879 dot 10009 at redhat dot com>
On Mon, 2013-08-19 at 13:56 -0600, Jeff Law wrote:
> On 08/02/2013 07:48 PM, David Malcolm wrote:
> > GDB 7.0 onwards supports hooks written in Python to improve the
> > quality-of-life within the debugger. The best known are the
> > pretty-printing hooks [1], which we already use within libstdc++ for
> > printing better representations of STL containers.
> So as I mentioned during the Cauldron, I really like this and feel it
> could simplify certain aspects of debugging. What's even better is we
> can easily twiddle this stuff to further improve the experience as we
> use it more. Of course I'm particularly interested in blocks & edges,
> so that's where you'll probably see further feedback from me.
>
> [ ... ]
>
> >
> > Note that this doesn't eliminate the .gdbinit script that some people
> > use, but it's arguably far superior, in that it happens automatically,
> > and for all values that are printed e.g. in backtraces, viewing struct
> > fields, etc.
> Right.
>
> >
> > I'd like to get this into trunk. Some remaining issues:
> > * installation; currently one has to manually copy it into place, as
> > noted above; it would be nice to automate things so that during a build
> > it gets copied to cc1-gdb.py, cc1plus-gdb.py etc
> Perhaps add -iex "add-auto-load-safe-path <gcc source path>" in
> .gdbinit? I can't imagine typing that every time I start up...
I came up with a simpler approach to this that doesn't require copying
things into place, and reuses the permissions already granted to
$builddir/gcc/.gdbinit; see:
http://gcc.gnu.org/ml/gcc-patches/2013-08/msg01532.html
This other approach does link enablement of the Python hooks to that of
the older hooks. I thought this is worth mentioning, though I don't see
it as a problem.
> > * it hardcoded values in a few places rather than correctly looking up
> > enums
> > * the kludge in the RTX printer mentioned above.
> Given this stuff is in python, I'm comfortable letting you own it and
> decide if/when/how to fix these warts.
Thanks; v3 of the patch (linked to above) would add me to the
MAINTAINERS file for this aspect.