Re: [PATCHv5 01/11] gdb: include breakpoint number in testing condition error message

[Andrew Burgess <aburgess@redhat.com>]

Andrew Burgess <aburgess@redhat.com> writes:

> When GDB fails to test the condition of a conditional breakpoint, for
> whatever reason, the error message looks like this:
>
>   (gdb) break foo if (*(int *) 0) == 1
>   Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
>   (gdb) r
>   Starting program: /tmp/bpcond
>   Error in testing breakpoint condition:
>   Cannot access memory at address 0x0
>
>   Breakpoint 1, foo () at bpcond.c:11
>   11	  int a = 32;
>   (gdb)
>
> The line I'm interested in for this commit is this one:
>
>   Error in testing breakpoint condition:
>
> In the case above we can figure out that the problematic breakpoint
> was #1 because in the final line of the message GDB reports the stop a
> breakpoint #1.
>
> However, in the next few patches I plan to change this.  In some cases
> I don't think it makes sense for GDB to report the stop as being at
> breakpoint #1, consider this case:
>
>   (gdb) list some_func
>   1	int
>   2	some_func ()
>   3	{
>   4	  int *p = 0;
>   5	  return *p;
>   6	}
>   7
>   8	void
>   9	foo ()
>   10	{
>   (gdb) break foo if (some_func ())
>   Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
>   (gdb) r
>   Starting program: /tmp/bpcond
>
>   Program received signal SIGSEGV, Segmentation fault.
>   0x0000000000401116 in some_func () at bpcond.c:5
>   5	  return *p;
>   Error in testing breakpoint condition:
>   The program being debugged was signaled while in a function called from GDB.
>   GDB remains in the frame where the signal was received.
>   To change this behavior use "set unwindonsignal on".
>   Evaluation of the expression containing the function
>   (some_func) will be abandoned.
>   When the function is done executing, GDB will silently stop.
>
>   Program received signal SIGSEGV, Segmentation fault.
>
>   Breakpoint 1, 0x0000000000401116 in some_func () at bpcond.c:5
>   5	  return *p;
>   (gdb)
>
> Notice that, the final lines of output report the stop as being at
> breakpoint #1, even though we are actually located within some_func.
>
> I find this behaviour confusing, and propose that this should be
> changed.  However, if I make that change then every reference to
> breakpoint #1 will be lost from the error message.
>
> So, in this commit, in preparation for the later commits, I propose to
> change the 'Error in testing breakpoint condition:' line to this:
>
>   Error in testing condition for breakpoint NUMBER:
>
> where NUMBER will be filled in as appropriate.  Here's the first
> example with the updated error:
>
>   (gdb) break foo if (*(int *) 0) == 0
>   Breakpoint 1 at 0x40111e: file bpcond.c, line 11.
>   (gdb) r
>   Starting program: /tmp/bpcond
>   Error in testing condition for breakpoint 1:
>   Cannot access memory at address 0x0
>
>   Breakpoint 1, foo () at bpcond.c:11
>   11	  int a = 32;
>   (gdb)
>
> The breakpoint number does now appear twice in the output, but I don't
> see that as a negative.
>
> This commit just changes the one line of the error, and updates the
> few tests that either included the old error in comments, or actually
> checked for the error in the expected output.
>
> As the only test that checked the line I modified is a Python test,
> I've added a new test that doesn't rely on Python that checks the
> error message in detail.
>
> While working on the new test, I spotted that it would fail when run
> with native-gdbserver and native-extended-gdbserver target boards.
> This turns out to be due to a gdbserver bug.  To avoid cluttering this
> commit I've added a work around to the new test script so that the
> test passes for the remote boards, in the next few commits I will fix
> gdbserver, and update the test script to remove the work around.

I went ahead and pushed this commit.

If there are any problems, please let me know, I'm happy to address any
issues.

Thanks,
Andrew