does bpstat_print stop printing prematurely?

does bpstat_print stop printing prematurely?

[Doug Evans]

Does bpstat_print stop printing prematurely?  I think it does.

  for (; bs; bs = bs->next)
    {
      val = print_bp_stop_message (bs);
      if (val == PRINT_SRC_ONLY 
	  || val == PRINT_SRC_AND_LOC 
	  || val == PRINT_NOTHING)
	return val;
    }

What if there is 1 breakpoint that triggers and two watchpoints?

As a user, whenever execution stops I'd kinda like to know which
of all of my active watchpoints triggered without having to
manually examine each one.

Things are even more confusing if gdb prints some but not all
of the triggering watchpoints.

Example: Suppose the `bs' arg to bpstat_print contains a watchpoint,
a pc breakpoint, and another watchpoint, in that order.

Currently bpstat_print will print the first watchpoint and the
pc breakpoint but not the second watchpoint.  Blech.

I'll file a pr unless something can rationalize the current behaviour.

Re: does bpstat_print stop printing prematurely?

[Eli Zaretskii]

On Mon, 15 Apr 2002, Doug Evans wrote:

> What if there is 1 breakpoint that triggers and two watchpoints?

Do you actually have an example of this, or can craft one?

You see, I think it's all but impossible to have a breakpoint and a 
watchpoint trigger at the same PC.  That's because the CPU carefully 
designs its faults and traps so that one always preceeds the other.  
(For soft breakpoints, the ones implemented by inserting a breakpoint 
opcode into the code, doing so overwrites the instruction that would 
have caused a watchpoint to trigger, so the simultaneous triggering is 
again impossible.)

> As a user, whenever execution stops I'd kinda like to know which
> of all of my active watchpoints triggered without having to
> manually examine each one.

GDB should already cite all the watchpoints that trigger, unless there's 
a bug.  Again, please provide a specific example of a failure, if you can.

> Things are even more confusing if gdb prints some but not all
> of the triggering watchpoints.

Cannot reproduce this on my machine with GDB 5.1.1: if I set two 
watchpoints on the same address, GDB announces both of them.  Please tell 
what OS did you try that on, and which version of GDB was that.

> Example: Suppose the `bs' arg to bpstat_print contains a watchpoint,
> a pc breakpoint, and another watchpoint, in that order.
> 
> Currently bpstat_print will print the first watchpoint and the
> pc breakpoint but not the second watchpoint.  Blech.

An example program that exhibits this behavior would be nice.  Thanks.

Re: does bpstat_print stop printing prematurely?

[Doug Evans]

Eli Zaretskii writes:
 > Do you actually have an example of this, or can craft one?

Trivially.

 > You see, I think it's all but impossible to have a breakpoint and a 
 > watchpoint trigger at the same PC.  That's because the CPU carefully 
 > designs its faults and traps so that one always preceeds the other.

Nope.  When control stops, all gdb may know is that _some_ breakpoint hit.
[where "breakpoint" here includes "watchpoint" but no matter]
Some targets may assist gdb in partially distinguishing them, but
such a distinction is insufficient.

Note for example that you can have multiple pc breakpoints at the
same location.  This is useful if each has its own condition and commands.
When execution stops, gdb can't know which of the two triggered because
it hasn't evaluated the conditions yet.  The distinction between the
two is a gdb artifact and there's nothing the O/S (*) can do to tell
gdb which of the two fired: all gdb told the O/S was "stop at this pc
value please."

Thus when execution stops there can be several reasons.
The `stop_bpstat' list records all of them.
And gdb makes an effort to print all of them (or some of them) which is great,
but it'd be nice if the effort was complete.

Now, if the gdb maintainers want to make the bug go away by defining
it away that's their prerogative.  It's a step backwards though.

(*): or embedded system or simulator or ... etc.

 > Cannot reproduce this on my machine with GDB 5.1.1: if I set two 
 > watchpoints on the same address, GDB announces both of them.  Please tell 
 > what OS did you try that on, and which version of GDB was that.

You need to recreate the conditions of having the stop_bpstat list contain
a watchpoint, then a pc breakpoint, then another watchpoint.
bpstat_print will stop printing at the pc breakpoint, but it hasn't
printed the final watchpoint yet.

Here's a session showing how to recreate it.

The first gdb session shows gdb printing all 3 breakpoints: two watchpoints
and a pc breakpoint.  It does this because of the order in which the 3 were
created.  The second gdb session shows gdb not printing the second watchpoint.
In this case the second watchpoint was created after the pc breakpoint.

A quick skim of the code will explain why gdb is behaving this way.
I'm hoping people will agree it's a bug rather than defining the problem away.

casey:~$ cat -n foo.c
     1	int foo;
     2	int bar;
     3	
     4	int
     5	main ()
     6	{
     7	    foo = 42;
     8	    return 0;
     9	}
casey:~$ gcc -g foo.c


casey:~$ gdb-5.1.1 a.out
GNU gdb 5.1.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) watch foo
Hardware watchpoint 1: foo
(gdb) cond 1 bar != -1
(gdb) watch foo
Hardware watchpoint 2: foo
(gdb) cond 2 bar >= 0
(gdb) b foo.c:8
Breakpoint 3 at 0x80483ad: file foo.c, line 8.
(gdb) b main
Breakpoint 4 at 0x80483a3: file foo.c, line 7.
(gdb) r
Starting program: /home/dje/a.out 
Hardware watchpoint 1: foo
Hardware watchpoint 2: foo
Hardware watchpoint 1: foo
Hardware watchpoint 2: foo

Breakpoint 4, main () at foo.c:7
7	    foo = 42;
(gdb) c
Continuing.
Hardware watchpoint 1: foo

Old value = 0
New value = 42
Hardware watchpoint 2: foo

Old value = 0
New value = 42

Breakpoint 3, main () at foo.c:8
8	    return 0;
(gdb) q
The program is running.  Exit anyway? (y or n) y


casey:~$ gdb-5.1.1 a.out
GNU gdb 5.1.1
Copyright 2002 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i686-pc-linux-gnu"...
(gdb) watch foo
Hardware watchpoint 1: foo
(gdb) cond 1 bar != -1
(gdb) b foo.c:8
Breakpoint 2 at 0x80483ad: file foo.c, line 8.
(gdb) watch foo
Hardware watchpoint 3: foo
(gdb) cond 3 bar >= 0
(gdb) b main
Breakpoint 4 at 0x80483a3: file foo.c, line 7.
(gdb) i b
Num Type           Disp Enb Address    What
1   hw watchpoint  keep y              foo
	stop only if bar != -1
2   breakpoint     keep y   0x080483ad in main at foo.c:8
3   hw watchpoint  keep y              foo
	stop only if bar >= 0
4   breakpoint     keep y   0x080483a3 in main at foo.c:7
(gdb) r
Starting program: /home/dje/a.out 
Hardware watchpoint 1: foo
Hardware watchpoint 3: foo
Hardware watchpoint 1: foo
Hardware watchpoint 3: foo

Breakpoint 4, main () at foo.c:7
7	    foo = 42;
(gdb) c
Continuing.
Hardware watchpoint 1: foo

Old value = 0
New value = 42

Breakpoint 2, main () at foo.c:8
8	    return 0;
(gdb) q
The program is running.  Exit anyway? (y or n) y
casey:~$ 

Re: does bpstat_print stop printing prematurely?

[Eli Zaretskii]

On Mon, 15 Apr 2002, Doug Evans wrote:

> Now, if the gdb maintainers want to make the bug go away by defining
> it away that's their prerogative.  It's a step backwards though.

I didn't say that the problem didn't exist, just that I didn't see it and 
couldn't reproduce it with a small test I tried.

Thanks for the example, I will look into it.

Re: does bpstat_print stop printing prematurely?

[Eli Zaretskii]

> From: Doug Evans <dje@transmeta.com>
> Date: Mon, 15 Apr 2002 23:43:34 -0700 (PDT)
> 
> Here's a session showing how to recreate it.

Thanks, I reproduced the bug on my machine.  However, I don't know
what would it take to fix this, since I don't understand the comment
in bpstat_print before the offending loop.  Anybody?

Re: does bpstat_print stop printing prematurely?

[Doug Evans]

Eli Zaretskii writes:
 > > From: Doug Evans <dje@transmeta.com>
 > > Date: Mon, 15 Apr 2002 23:43:34 -0700 (PDT)
 > > 
 > > Here's a session showing how to recreate it.
 > 
 > Thanks, I reproduced the bug on my machine.  However, I don't know
 > what would it take to fix this, since I don't understand the comment
 > in bpstat_print before the offending loop.  Anybody?

Assuming one decides to print all breakpoints, either move the
control for source/frame printing into bpstat_print or pull
the loop in bpstat_print into normal_stop().

Also, in the case of pc breakpoints, there's no need to print the
source line for each one.  Printing that only once would be fine.
[maybe "printing" it multiple times would confuse programs parsing
the output]

You might even want to do a preprocessing pass and sort them.
Since bpstat_print wants to stop when it wants the caller to print
the source location (Vega, right smack dab in the middle, but I digress),
maybe the thing to do is print all non-pc-breakpoints first, then
all pc-breakpoints last, defering the source location to the last
pc breakpoint.
Maybe the preprocessing pass would be where `print_it_done' is handled
and nothing is printed, even if other breakpoints want to be printed.

Re: does bpstat_print stop printing prematurely?

[Doug Evans]

I wrote:
 > Assuming one decides to print all breakpoints, either move the
 > control for source/frame printing into bpstat_print or pull
 > the loop in bpstat_print into normal_stop().

Hmmm... another possibility is to do neither.
Instead, with the preprocessing pass in bpstat_print one
could early exit if printit_done is found, otherwise print
all the non-pc breakpoints first, then print all the pc-breakpoints last,
and then return one of `print_stop_action'.

That's requires a minimal amount of change and feels safest.
The only issue is whether programs that parse the output would
get confused if multiple pc breakpoints get reported.
The source location would still only be printed once so I'm guessing
it's ok, but someone with some knowledge of all the various
programs that parse the output should be consulted.

Re: does bpstat_print stop printing prematurely?

[Andrew Cagney]

>  > Assuming one decides to print all breakpoints, either move the
>  > control for source/frame printing into bpstat_print or pull
>  > the loop in bpstat_print into normal_stop().
> 
> Hmmm... another possibility is to do neither.
> Instead, with the preprocessing pass in bpstat_print one
> could early exit if printit_done is found, otherwise print
> all the non-pc breakpoints first, then print all the pc-breakpoints last,
> and then return one of `print_stop_action'.
> 
> That's requires a minimal amount of change and feels safest.
> The only issue is whether programs that parse the output would
> get confused if multiple pc breakpoints get reported.
> The source location would still only be printed once so I'm guessing
> it's ok, but someone with some knowledge of all the various
> programs that parse the output should be consulted.

Hmm,

Yes, I agree with the comment about not reporting multiple watchpoint 
trigers is a bug.  As for breakpoints, normal behavour is to just report 
the first real breakpoint - you've previously been advised that you've 
multiple breakpoints and I'm guessing this [unfortunatly] is behind the 
early loop exit.

The functions that handle bpstat are in bad shape anyway.  One function 
should analyze the stop reason creating the list.  A second function 
should use this list to decide what to print.  MI needs this separation 
to be able to report stop events reliably.

Anyway, suggest at least bug-reporting it.

Andrew