On Tue, Aug 05, 2014 at 05:02:57PM -0400, David Malcolm wrote:
> On Wed, 2014-07-30 at 10:07 +0200, Richard Biener wrote:
> > On Tue, Jul 29, 2014 at 10:44 PM, David Malcolm <dmalc...@redhat.com> wrote:
> > > A complaint I heard at Cauldron with the C++ification of GCC passes is
> > > that it's become much more difficult to set breakpoints on the execute
> > > hooks of a pass, now that the passes are classes within anonymous
> > > namespaces.
> > >
> > > When this was first done, the execute methods were trivial
> > > implementations that called into the existing named functions, which are
> > > still easy to put a breakpoint on by name (assuming you know the name of
> > > the function), but some of these have now been converted so that the
> > > "execute" method is the body of the pass.
> > >
> > > I did some experimentation, on this box with
> > > gdb-7.6.50.20130731-19.fc20.x86_64 and gcc trunk r212913 (the latter
> > > from a week ago).
> > >
> > > You *can* set a breakpoint by name on such an execute method, but it's
> > > tedious to type:
> > > (gdb) break '(anonymous namespace)::pass_expand::execute'
> > > Breakpoint 7 at 0x655220: file ../../src/gcc/cfgexpand.c, line
> > >
> > > ...since tab-completion doesn't work well:
> > >
> > > (gdb) break '(a<TAB>
> > > does tab complete to:
> > > (gdb) break '(anonymous namespace)::
> > >
> > > but typing anything else then hitting tab returns back to:
> > > (gdb) break '(anonymous namespace)::
> > >
> > > Is anyone else seeing this?
> >
> > Yes, I filed a gdb bug about this.
> >
> > > I had a go at implementing a workaround, for the lack of tab completion
> > > (and the general verbosity) using gdbhooks.py.
> > >
> > > Attached is a patch to gdbhooks.py which adds a new command
> > > "break-on-pass" to gdb; in particular, it locates and parses passes.def,
> > > so that it can tab-complete on pass classnames:
> > >
> > > Example of use from the script: putting a breakpoint on "final", i.e.
> > > classname "pass_final":
> > >
> > > (gdb) break-on-pass
> > > Press <TAB>; it autocompletes to "pass_":
> > > (gdb) break-on-pass pass_
> > > Press <TAB>:
> > > Display all 219 possibilities? (y or n)
> > > Press "n"; then type "f":
> > > (gdb) break-on-pass pass_f
> > > Press <TAB> to autocomplete to pass classnames beginning with "pass_f":
> > > pass_fast_rtl_dce pass_fold_builtins
> > > pass_feedback_split_functions pass_forwprop
> > > pass_final pass_fre
> > > pass_fixup_cfg pass_free_cfg
> > > Type "in<TAB>" to complete to "pass_final":
> > > (gdb) break-on-pass pass_final
> > > ...and hit <RETURN>:
> > > Breakpoint 6 at 0x8396ba: file ../../src/gcc/final.c, line 4526.
> > > ...and we have a breakpoint set; continue execution:
> > > (gdb) cont
> > > Continuing.
> > > Breakpoint 6, (anonymous namespace)::pass_final::execute
> > > (this=0x17fb990) at ../../src/gcc/final.c:4526
> > > 4526 virtual unsigned int execute (function *) { return
> > > rest_of_handle_final (); }
> > >
> > > This assumes you've suitably enabled gdbhooks.py, as documented at the
> > > top of that file.
> > >
> > > Thoughts?
> >
> > Works for me though I'm not able to review python ;)
>
> I've gone ahead and committed it to trunk as r213646; hope this reduces
> the pain somewhat.
So, I was thinking about this more at some point. iirc the reason to
put the classes in the anon namespace was to get stuff devirtualized.
However I think we can just use __final if building with gcc to
acomplish the same thing, and then remove the namespace {}s. It needs
to be tested, but if it works it would be even better :-)
Trev
>
> > Richard.
> >
> > > Dave
> > >
> > > gcc/
> > > * gdbhooks.py (find_gcc_source_dir): New helper function.
> > > (class PassNames): New class, locating and parsing passes.def.
> > > (class BreakOnPass): New command "break-on-pass".
> > >
>
>
