Re: [PATCH v2] dynamic printf

[Stan Shebs <stanshebs@earthlink.net>]

On 5/16/12 1:17 PM, Tom Tromey wrote:
>>>>>> "Stan" == Stan Shebs<stanshebs@earthlink.net>  writes:
> Sorry about the delay on this.
>
> Stan>  +  /* Manufacture a printf/continue sequence.  */
> Stan>  +  if (printf_line)
> Stan>  +    {
> Stan>  +      struct command_line *printf_cmd_line, *cont_cmd_line = NULL;
> Stan>  +
> Stan>  +      cont_cmd_line = xmalloc (sizeof (struct command_line));
> Stan>  +      cont_cmd_line->control_type = simple_control;
> Stan>  +      cont_cmd_line->body_count = 0;
> Stan>  +      cont_cmd_line->body_list = NULL;
> Stan>  +      cont_cmd_line->next = NULL;
> Stan>  +      cont_cmd_line->line = xstrdup ("continue");
> Stan>  +
> Stan>  +      printf_cmd_line = xmalloc (sizeof (struct command_line));
> Stan>  +      printf_cmd_line->control_type = simple_control;
> Stan>  +      printf_cmd_line->body_count = 0;
> Stan>  +      printf_cmd_line->body_list = NULL;
> Stan>  +      printf_cmd_line->next = cont_cmd_line;
> Stan>  +      printf_cmd_line->line = printf_line;
> Stan>  +
> Stan>  +      breakpoint_set_commands (b, printf_cmd_line);
>
> I thought this approach would break "next"ing over a dprintf location.

Indeed, thus this part of the introduction to this patch: :-)

"... Joel previously noted a problem with the "continue" in the command 
list, which is that stepping/nexting over a dprintf becomes a continue 
instead (this is a problem for general breakpoint command lists as 
well).  I tinkered with bpstats a bit, but didn't come up with a good 
solution.  One possibility might be a new pseudo-command for breakpoint 
command lists, that resumes the program using the same proceed() 
arguments as the command that caused the breakpoint hit."

If nobody comes up with a good idea here, it should probably be 
documented as a limitation.  I wonder if some relatively recent infrun 
tinkering changed the breakpoint command behavior - you'd think 
*somebody* would have bumped into it sometime in the past 20 years...

Ironically, the agent version doesn't have this problem, because the 
resume happens automatically inside GDBserver, and GDB is oblivious.


> Stan>  +void
> Stan>  +dprintf_command (char *arg, int from_tty)
>
> I think this could be static.
>

Good point, I tweaked it for the agent patch.

Stan