This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
DPrintf feedback (was: [RFC] PR 15075 dprintf interferes with "next")
- From: Marc Khouzam <marc dot khouzam at ericsson dot com>
- To: 'Yao Qi' <yao at codesourcery dot com>, "'gdb-patches at sourceware dot org'" <gdb-patches at sourceware dot org>
- Cc: "'tromey at redhat dot com'" <tromey at redhat dot com>, 'Pedro Alves' <palves at redhat dot com>, 'Joel Brobecker' <brobecker at adacore dot com>, 'Stan Shebs' <stanshebs at earthlink dot net>
- Date: Fri, 22 Feb 2013 17:38:50 +0000
- Subject: DPrintf feedback (was: [RFC] PR 15075 dprintf interferes with "next")
- References: <1361192891-29341-1-git-send-email-yao@codesourcery.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