This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GDB hooks for debugging GCC


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]