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: [PATCH] Add dotfn


On Mon, 3 Jul 2017, Tom de Vries wrote:

> On 07/03/2017 09:05 AM, Richard Biener wrote:
> > On Mon, 3 Jul 2017, Tom de Vries wrote:
> > 
> > > Hi,
> > > 
> > > this patch adds a debug function dotfn and a convenience macro DOTFN
> > > similar
> > > to dot-fn in gdbhooks.py.
> > > 
> > > It can be used to have the compiler:
> > > - dump a control flow graph, or
> > > - pop up a control flow graph window
> > > at specific moments in the compilation flow, for debugging purposes.
> > > 
> > > Bootstrapped and reg-tested on x86_64.
> > > 
> > > Used for debugging PR81192.
> > > 
> > > OK for trunk?
> > 
> > Why's dot-fn not enough? > I'd rather extend stuff in gdbhooks.py than
> > adding this kind of stuff to gcc itself.
> 
> When expressing where and when to dump or pop-up a control flow graph,
> sometimes it's easier for me to do that in C than in gdb scripting.

Ah, you mean by patching GCC.  Yeah, I can see that this is useful
in some cases.  OTOH I had dot-fn this way in my local dev tree for
a few years ...

I'm retracting my objection but leave approval to somebody else
just to see if we can arrive at any consensus for "advanced"
debug stuff in GCC itself.

For my usecase the gdb python stuff is now nearly perfect -- apart
from the cases where graph generation ICEs (like corrupt loop info).

Richard.


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