DPrintf feedback (was: [RFC] PR 15075 dprintf interferes with "next")

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

Hi,

Yao posting a patch for dprintf was good timing.
I've been working on integrating the dprintf feature
into Eclipse and I ran into some issues.

I think the main point to discuss is the fact that
dprintf use breakpoint commands.  This has been put in question,
a couple of times on the mailing list I believe.  An impact
of that approach is that although in CLI, dprintf are silent 
breakpoints, they don't seem to be in MI.  When I put a dprintf 
in a loop and run over it, I get a bunch of *stopped/*running 
events and =breakpoint-modified events.

I'm not sure how I feel about the =break-modified event just yet
and your expert opinion would be appreciated.  However, the 
*stopped/*running events seem like they shouldn't be there.
They cause a lot of un-needed communication between Eclipse and GDB.

This gives me the feeling that it would be better to have dprintf
behave like an active tracepoint instead of a breakpoint.  I believe
Joel had suggested that at one point.

Such an approach may also help fix the "continue" problem
that Yao is trying to address.  I seem to recall that Hui had posted 
patches to add some kind of 'printf' tracepoint command.  Maybe that 
would be something that can help?

Also, as pointed out by Pedro, the user is able to modify the 
dprintf breakpoint commands, which can suddenly turn a dprintf
into something else, although GDB still has it tagged as 'dprintf'.
The fact that GDB has a new type 'dprintf', implies that dprintf
should keep their 'dprintf' properties, and not be turned into
a standard bp.

Other issues I ran across are below.  I wasn't sure opening PRs was
the way to do since those issues may disappear if the current 
implementation is amended:

- If I set a condition on a dprintf, things don't behave right.
  When the condition is false, the printout is not shown, but the 
  dprintf causes the inferior to stop and not continue.

- Setting the dprintf-style to 'agent' for a local session defaults
  to 'gdb' style, but the 'continue' command is not added in that 
  case (easy to fix)

- Pagination is triggered for dprintf in CLI mode, at least when
  using dprintf-style 'gdb'.  I think this is a problem because:
   a) when pagination is triggered, inferior execution will be 
      interrupted until the user answers the pagination prompt
   b) pagination is triggered by the dprintf but not by real 
      inferior output. So, as dprintf and inferior printouts 
      appear interleaved on the screen, the pagination prompt 
      will be triggered when the dprintfs add up to too many, 
      which will seem random to the user, since the other 
      printouts are also visible.

- In Eclipse, the dprintf-style that makes sense is either 
  'call' or 'agent'.  'call' will call 'printf' in the inferior.
  With GDB 7.5, GDB cannot call an inferior method on Ubuntu, 
  which is a serious limitation for eclipse/dprintf.
  http://sourceware.org/ml/gdb-patches/2012-07/msg00037.html

- Updating the dprintf-style to 'agent' for existing dprintfs 
  will cause: "May only run agent-printf on the target" when 
  it is time to print.

- The fact that there is no expression checking on the validity 
  of the dprintf string can be a user-friendliness problem

- Output buffering is not behaving as a real printf.  For 
  example, if my program does
     printf("hello");
     printf("friend\n");
and I put a dprintf " my " on the second line, 
I would expect to see
   "hello my friend"
but instead I see
   " my hellofriend"
which shows that the dprintf string does not go to the same 
buffer as the real printfs, and is flushed earlier.
This also happens with the dprintf-style "agent"

Thanks 

Marc