Re: [RFAv3] Show locno for 'multi location' breakpoint hit msg+conv var $bkptno $locno.

[Tom Tromey <tom@tromey.com>]

>>>>> "Philippe" == Philippe Waroquiers via Gdb-patches <gdb-patches@sourceware.org> writes:

Hi.  Thanks for the patch.  I'm sorry about the long delay on the
review.  I'm not really sure what to do about it but I think we need to
make some change here, because too many patches are falling into this
"10 pings" hole.

Philippe> Before this patch, when a breakpoint that has multiple locations is reached,
Philippe> GDB printed:
Philippe>   Thread 1 "zeoes" hit Breakpoint 1, some_func () at somefunc1.c:5

Philippe> This patch changes the message so that bkpt_print_id prints the precise
Philippe> encountered breakpoint:
Philippe>   Thread 1 "zeoes" hit Breakpoint 1.2, some_func () at somefunc1.c:5

Philippe> In mi mode, bkpt_print_id also (optionally) prints a new table field "locno":
Philippe>   locno is printed when the breakpoint has more than one location.
Philippe> Note that according to the GDB user manual node 'GDB/MI Development and Front
Philippe> Ends', it is ok to add new fields without changing the MI version.

I think the idea as a whole is sound, thank you for tackling this.

Philippe> Also, when a breakpoint is reached, the convenience variables
Philippe> $bkptno and $locno are set to the encountered breakpoint number
Philippe> and location number.

I believe we have a convention that new internally-created convenience
variables will start with "_".

I wondered a little whether we wanted to introduce $_bkptno or just
repurpose the already-existing $bpnum, but I see we already do this kind
of thing for tracepoints, and I suppose having different variables for
different semantics is good... it's just a bit unfortunate that the
names are similar.

Note that the breakpoint number convenience variable is
https://sourceware.org/bugzilla/show_bug.cgi?id=12464, so this should
be in a Bug: trailer and also mentioned in the form "PR breakpoints/12464"
somewhere in the commit message.

Philippe> +Inside a command list, you can use the command
Philippe> +@kbd{disable $bkptno} to disable the encountered breakpoint.
Philippe> +
Philippe> +If your breakpoint has several code locations, the command
Philippe> +@kbd{disable $bkptno.$locno} will disable the specific breakpoint code
Philippe> +location encountered.

It may be worth mentioning that the $_bkptno.$_locno form will work even
when your breakpoint only has a single location, and also the ".1"
special case for single-location breakpoints.

Philippe> @@ -8494,7 +8494,21 @@ print_stop_location (const target_waitstatus &ws)
Philippe>       LOCATION: Print only location
Philippe>       SRC_AND_LOC: Print location and source line.  */
Philippe>    if (do_frame_printing)
Philippe> -    print_stack_frame (get_selected_frame (NULL), 0, source_flag, 1);
Philippe> +    {
Philippe> +      if (tp->control.stop_bpstat != nullptr)
Philippe> +	{
Philippe> +	  const struct breakpoint *b = tp->control.stop_bpstat->breakpoint_at;
Philippe> +
Philippe> +	  if (b != nullptr)
Philippe> +	    {
Philippe> +	      int locno = bpstat_locno (tp->control.stop_bpstat);
Philippe> +	      set_internalvar_integer (lookup_internalvar ("bkptno"), b->number);
Philippe> +	      set_internalvar_integer (lookup_internalvar ("locno"),
Philippe> +				       (locno > 0 ? locno : 1));

This is in print_stop_location - but what if the location is not
printed?

I am curious if these variables can be, are intended to be, or should be
usable from breakpoint conditions or silent 'commands'.

I suspect maybe bpstat_do_actions_1 is a better spot for this, though
I'm not really sure.

Tom