RE: [PATCH] dynamic printf

[Marc Khouzam <marc.khouzam@ericsson.com>]

> -----Original Message-----
> From: gdb-patches-owner@sourceware.org 
> [mailto:gdb-patches-owner@sourceware.org] On Behalf Of Stan Shebs
> Sent: Tuesday, March 13, 2012 7:09 PM
> To: Andreas Schwab
> Cc: gdb-patches@sourceware.org
> Subject: Re: [PATCH] dynamic printf
> 
> On 2/29/12 1:14 AM, Andreas Schwab wrote:
> > Stan Shebs<stanshebs@earthlink.net>  writes:
> >
> >> This patch implements a "dynamic printf", which is 
> basically a breakpoint
> >> with a printf;continue as its command list - but with 
> additional features
> >> that make it more interesting.
> > How about:
> >
> > break [LOCATION] [thread THREADNUM] [if CONDITION] [printf 
> FORMAT,ARGS...]

When I tried it a while back, using a breakpoint + printf printed
to the GDB console.  The new dprintf has the goal of printing to the 
inferior's console.

With dprintf, the resulting printouts should look exactly the
same as if the user had added the printf in the code + recompiled.
Another way to achieve this may be to have a new
'inferior-printf' command similar to GDB's 'printf'
then
  break [LOCATION] [thread THREADNUM] [if CONDITION] [inferior-printf FORMAT,ARGS...]
would work too, I think.
However, one would loose the disconnected printing aspect of
the feature, which also makes it much closer to actually adding
a real printf in the code.

> I've been wondering whether that might be a better idea.  An 
> advantage 
> of "dprintf" for the command line is that it can abbreviate 
> to just "dp" 
> and tab completion works, while the optional arguments to the break 
> command don't have any way to abbreviate (although they probably 
> could).  That's not super-compelling, as by its nature a 
> printf command 
> entails typing in format string, double quotes and newlines 
> and all, and 
> in practice I expect a lot of these will tend to accumulate 
> in script files.
> 
> Another consideration is how the collection looks in an info break 
> command.  If dynamic prints are a different kind of 
> breakpoint, then you 
> can (in theory) filter the breakpoint listing to a single 
> category, but 
> if they are just breakpoints with special commands, they'll 
> continue to 
> be in the big list.
> 
> My intuition isn't giving me a strong read on which approach 
> users will 
> like better.  As the goal is at least partly to entice 
> printf()+recompile users into using a GDB command instead, I think it 
> needs to be among GDB's simpler commands.  Maybe include both 
> syntaxes, 
> mapping down to same functionality?

I think those points are good.
I personally don't have a strong opinion on those, since
I'm looking at it from the point of view of using this feature
from Eclipse.

BTW, I think this is one cool feature!

Marc