This is the mail archive of the mailing list for the GDB 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 v2] dynamic printf

On 5/16/12 1:17 PM, Tom Tromey wrote:
"Stan" == Stan Shebs<> 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.


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