[pushed 0/2] PR gdb/18002: bp-permanent.exp failures

[pushed 0/2] PR gdb/18002: bp-permanent.exp failures

[Pedro Alves]

I was a bit paranoid this morning with breakage the moribund locations
rework series might have caused, and looking over buildbot results I
got confused and thought I had caused bp-permanent.exp FAILs
PPC64/gdbserver is showing...  Only after fixing them did I realize
that I had compared the wrong gdb.sum files, and these failures are
pre-existing.  Oh well, here's the fix.  :-)

Pedro Alves (2):
  PR gdb/18002: Fix reinsert of a permanent breakpoints
  gdb.base/bp-permanent.exp: Tighten regex

 gdb/ChangeLog                           |  6 ++++++
 gdb/testsuite/ChangeLog                 |  4 ++++
 gdb/mem-break.c                         | 11 ++++++++++-
 gdb/testsuite/gdb.base/bp-permanent.exp |  2 +-
 4 files changed, 21 insertions(+), 2 deletions(-)

-- 
1.9.3

[pushed 2/2] gdb.base/bp-permanent.exp: Tighten regex

[Pedro Alves]

Trying to fix a permanent breakpoints bug, I broke "next" over a
regular breakpoint.  "next" would immediately hit the breakpoint the
program was already stopped at.  But, the "next over setup" test
failed to notice this and still issued a pass.  That's because the
regex matches "testsuite" in:

  Breakpoint 2 at 0x400687: file src/gdb/testsuite/gdb.base/bp-permanent.c, line 46.

gdb/testsuite/ChangeLog:
2015-03-05  Pedro Alves  <palves@redhat.com>

	* gdb.base/bp-permanent.exp: Tighten "next over setup" regex.
---
 gdb/testsuite/ChangeLog                 | 4 ++++
 gdb/testsuite/gdb.base/bp-permanent.exp | 2 +-
 2 files changed, 5 insertions(+), 1 deletion(-)

diff --git a/gdb/testsuite/ChangeLog b/gdb/testsuite/ChangeLog
index 1a76cc8..dd98483 100644
--- a/gdb/testsuite/ChangeLog
+++ b/gdb/testsuite/ChangeLog
@@ -1,3 +1,7 @@
+2015-03-05  Pedro Alves  <palves@redhat.com>
+
+	* gdb.base/bp-permanent.exp: Tighten "next over setup" regex.
+
 2015-03-04  Simon Marchi  <simon.marchi@ericsson.com>
 
 	* lib/mi-support.exp (mi_expect_interrupt): Accept
diff --git a/gdb/testsuite/gdb.base/bp-permanent.exp b/gdb/testsuite/gdb.base/bp-permanent.exp
index d0ed991..81a5293 100644
--- a/gdb/testsuite/gdb.base/bp-permanent.exp
+++ b/gdb/testsuite/gdb.base/bp-permanent.exp
@@ -96,7 +96,7 @@ proc test {always_inserted sw_watchpoint} {
 
 	# Run the "setup" function in the inferior.  This memcpy's the
 	# breakpoint instruction to a buffer in the inferior.
-	gdb_test "next" "test.*" "next over setup"
+	gdb_test "next" "test_basics \\(\\).*" "next over setup"
 
 	delete_breakpoints
 
-- 
1.9.3

[pushed 1/2] PR gdb/18002: Fix reinsert of a permanent breakpoints

[Pedro Alves]

When we find out that a breakpoint is set on top of a program
breakpoint, we mark it as "permanent".  E.g.,:

...
  if (bp_loc_is_permanent (loc))
    {
      loc->inserted = 1;
      loc->permanent = 1;
    }
...

Note we didn't fill in the breakpoint's shadow (shadow_len remains 0).

In case the target claims support for evaluating breakpoint
conditions, GDB sometimes reinserts breakpoints that are already
inserted (to update the conditions on the target side).  Since GDB
doesn't know whether the target supports evaluating conditions _of_
software breakpoints (vs hardware breakpoints, etc.) until it actually
tries it, if the target doesn't actually support z0 breakpoints, GDB
ends up reinserting a GDB-managed software/memory breakpoint
(mem-break.c).

And that is the case that is buggy: breakpoints that are marked
inserted contribute their shadows (if any) to the memory returned by
target_read_memory, to mask out breakpoints.  Permanent breakpoints
are always marked as inserted.  So if the permanent breakpoint doesn't
have a shadow yet in its shadow buffer, but we set shadow_len before
calling target_read_memory, then the still clear shadow_contents
buffer will be used by the breakpoint masking code...  And then from
there on, the permanent breakpoint has a broken shadow buffer, and
thus any memory read out of that address will read bogus code, and
many random bad things fall out from that.

The fix is just to set shadow_len at the same time shadow_contents is
set, not one before and another after...

Fixes all gdb.base/bp-permanent.exp FAILs on PPC64 GNU/Linux gdbserver
and probably any other gdbserver port that doesn't do z0 breakpoints.

gdb/ChangeLog:
2015-03-05  Pedro Alves  <palves@redhat.com>

	PR gdb/18002
	* mem-break.c (default_memory_insert_breakpoint): Set shadow_len
	after reading the breakpoint's shadow memory.
---
 gdb/ChangeLog   |  6 ++++++
 gdb/mem-break.c | 11 ++++++++++-
 2 files changed, 16 insertions(+), 1 deletion(-)

diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 5ee18e7..bfb584c 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,9 @@
+2015-03-05  Pedro Alves  <palves@redhat.com>
+
+	PR gdb/18002
+	* mem-break.c (default_memory_insert_breakpoint): Set shadow_len
+	after reading the breakpoint's shadow memory.
+
 2015-03-05  Mark Kettenis  <kettenis@gnu.org>
 
 	* hppabsd-nat.c: Remove file.
diff --git a/gdb/mem-break.c b/gdb/mem-break.c
index aeffc93..0fb53cf 100644
--- a/gdb/mem-break.c
+++ b/gdb/mem-break.c
@@ -53,12 +53,21 @@ default_memory_insert_breakpoint (struct gdbarch *gdbarch,
 
   /* Save the memory contents in the shadow_contents buffer and then
      write the breakpoint instruction.  */
-  bp_tgt->shadow_len = bplen;
   readbuf = alloca (bplen);
   val = target_read_memory (addr, readbuf, bplen);
   if (val == 0)
     {
+      /* These must be set together, either before or after the shadow
+	 read, so that if we're "reinserting" a breakpoint that
+	 doesn't have a shadow yet, the breakpoint masking code inside
+	 target_read_memory doesn't mask out this breakpoint using an
+	 unfilled shadow buffer.  The core may be trying to reinsert a
+	 permanent breakpoint, for targets that support breakpoint
+	 conditions/commands on the target side for some types of
+	 breakpoints, such as target remote.  */
+      bp_tgt->shadow_len = bplen;
       memcpy (bp_tgt->shadow_contents, readbuf, bplen);
+
       val = target_write_raw_memory (addr, bp, bplen);
     }
 
-- 
1.9.3

Re: [pushed 1/2] PR gdb/18002: Fix reinsert of a permanent breakpoints

[Yao Qi]

Pedro Alves <palves@redhat.com> writes:

> Permanent breakpoints
> are always marked as inserted.  So if the permanent breakpoint doesn't
> have a shadow yet in its shadow buffer, but we set shadow_len before
> calling target_read_memory, then the still clear shadow_contents
> buffer will be used by the breakpoint masking code...  And then from
> there on, the permanent breakpoint has a broken shadow buffer, and
> thus any memory read out of that address will read bogus code, and
> many random bad things fall out from that.

Yes, that is what I observed on aarch64-linux too.

>
> The fix is just to set shadow_len at the same time shadow_contents is
> set, not one before and another after...
>
> Fixes all gdb.base/bp-permanent.exp FAILs on PPC64 GNU/Linux gdbserver
> and probably any other gdbserver port that doesn't do z0 breakpoints.

This patch fixes gdb.base/bp-permanent.exp FAILs on aarch64-linux too,
but there are some remains, which are not related.

> diff --git a/gdb/mem-break.c b/gdb/mem-break.c
> index aeffc93..0fb53cf 100644
> --- a/gdb/mem-break.c
> +++ b/gdb/mem-break.c
> @@ -53,12 +53,21 @@ default_memory_insert_breakpoint (struct gdbarch *gdbarch,
>  
>    /* Save the memory contents in the shadow_contents buffer and then
>       write the breakpoint instruction.  */
> -  bp_tgt->shadow_len = bplen;
>    readbuf = alloca (bplen);
>    val = target_read_memory (addr, readbuf, bplen);
>    if (val == 0)
>      {
> +      /* These must be set together, either before or after the shadow
> +	 read, so that if we're "reinserting" a breakpoint that
> +	 doesn't have a shadow yet, the breakpoint masking code inside
> +	 target_read_memory doesn't mask out this breakpoint using an
> +	 unfilled shadow buffer.  The core may be trying to reinsert a
> +	 permanent breakpoint, for targets that support breakpoint
> +	 conditions/commands on the target side for some types of
> +	 breakpoints, such as target remote.  */
> +      bp_tgt->shadow_len = bplen;
>        memcpy (bp_tgt->shadow_contents, readbuf, bplen);
> +

Your fix looks right to me, although I am testing a different one, in
which bp_location_has_shadow returns false if bl->permanent is true.
Anyway, Thanks for fixing this bug, Pedro.

-- 
Yao (齐尧)

Re: [pushed 1/2] PR gdb/18002: Fix reinsert of a permanent breakpoints

[Pedro Alves]

On 03/06/2015 02:31 PM, Yao Qi wrote:

> Your fix looks right to me, although I am testing a different one, in
> which bp_location_has_shadow returns false if bl->permanent is true.
> Anyway, Thanks for fixing this bug, Pedro.

Yeah, I also considered that, though we'd likely end up needing more
special casing in other places: the setting of shadow_len before the
read and the shadow_contents afterwards looked so bogus that I
thought that even if we fixed this some other way, we should still
do what I had done.  And then I was seeing more fundamental brokenness
with permanent breakpoints and stopped at that point.  The other issues
I identified were:

- If the user manually changes memory at the permanent breakpoint
address, we should really write to the shadow buffer, not to
memory, and clear the permanent bp flag.  We don't do the latter.
Likewise, if the user writes an int3 manually where a breakpoint is
already set, we should mark the breakpoint as permanent.  I suspect
that filling the shadow buffer (with a software breakpoint) immediately
when we detect the program breakpoint (bp_loc_is_permanent's caller)
would make things simpler, considering targets where the breakpoint
is longer than one byte, and writes to only parts of the breakpoint.

- I also considered completely getting rid of the ->permanent
flag, and then in places where we need to know whether we stopped
at one (to step over it), we would check if the shadow contains
a software breakpoint.  The case that gave me pause was hardware
breakpoints on top of a permanent bp, which don't have a shadow.
Or we could even always check if there's a program breakpoint at
PC that we should skip by manually advancing the PC, even if there's
no user breakpoint on top...  The trick will be to try to avoid
the extra memory read.  But maybe either that doesn't matter in
practice, given that we should limit that for when the program had
stopped for a SIGTRAP, and, SIGTRAP isn't set to "pass", and the PC
it still the PC the thread had when it stopped.  Hmm...

Thanks,
Pedro Alves