[rfc] [4/4] SPU overlay support: Bugfix in remove_breakpoint

[rfc] [4/4] SPU overlay support: Bugfix in remove_breakpoint

[Ulrich Weigand]

Hello,

this fixes a bug we discovered during SPU overlay testing.

The problem occurs when remove_breakpoint attempts to remove a
software breakpoint in an overlay section that is not currently
mapped.  The routine simply goes and writes the saved shadow
contents over that location -- but if another overlay section
is now mapped there, this will clobber its code.

The current behaviour was introduced by Michael Snyder's patch:
http://sourceware.org/ml/gdb-patches/2002-04/msg00149.html
to support hardware breakpoints in overlays.

And I guess if this is a hardware breakpoint, it *should* be
removed -- otherwise the overlay manager would have to fiddle
with hardware breakpoint registers when swapping overlays.

However, for *software* breakpoints this looks definitely 
wrong to me.  So the patch below restores the old behaviour
for those: the shadow contents are restored only if the 
section is still mapped.

Any comments?  I plan on committing this after the rest of
the SPU overlay support patches.

Bye,
Ulrich


ChangeLog:

	* breakpoint.c (remove_breakpoint): Do not remove software
	breakpoints in unmapped overlay sections.

diff -urNp gdb-orig/gdb/breakpoint.c gdb-head/gdb/breakpoint.c
--- gdb-orig/gdb/breakpoint.c	2007-05-06 16:07:05.000000000 +0200
+++ gdb-head/gdb/breakpoint.c	2007-05-07 22:44:15.698329784 +0200
@@ -1585,8 +1585,14 @@ remove_breakpoint (struct bp_location *b
 		 don't know what the overlay manager might do.  */
 	      if (b->loc_type == bp_loc_hardware_breakpoint)
 		val = target_remove_hw_breakpoint (&b->target_info);
-	      else
+
+	      /* However, we should remove *software* breakpoints only
+		 if the section is still mapped, or else we overwrite
+		 wrong code with the saved shadow contents.  */
+	      else if (section_is_mapped (b->section))
 		val = target_remove_breakpoint (&b->target_info);
+	      else
+		val = 0;
 	    }
 	  else
 	    {
-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [rfc] [4/4] SPU overlay support: Bugfix in remove_breakpoint

[Daniel Jacobowitz]

On Tue, May 08, 2007 at 12:27:05AM +0200, Ulrich Weigand wrote:
> However, for *software* breakpoints this looks definitely 
> wrong to me.  So the patch below restores the old behaviour
> for those: the shadow contents are restored only if the 
> section is still mapped.
> 
> Any comments?  I plan on committing this after the rest of
> the SPU overlay support patches.

I think that there's two reasonable overlay manager behaviors,
depending on the different sorts of systems that might want overlays.
If the source of the overlay comes from ROM, or from some other
read-only source, then your patch is clearly right.  If it comes from
RAM, then some systems may save the overlay (e.g. if it contained
data) - and thus save the breakpoint.  I can't see any way around this
unless the overlay manager warns GDB before it unmaps the breakpoint.

WDYT?

I'm not opposed to your patch, though, since SPU is probably the only
current user of GDB's overlay support.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [rfc] [4/4] SPU overlay support: Bugfix in remove_breakpoint

[Ulrich Weigand]

Daniel Jacobowitz wrote:
> On Tue, May 08, 2007 at 12:27:05AM +0200, Ulrich Weigand wrote:
> > However, for *software* breakpoints this looks definitely 
> > wrong to me.  So the patch below restores the old behaviour
> > for those: the shadow contents are restored only if the 
> > section is still mapped.
> > 
> > Any comments?  I plan on committing this after the rest of
> > the SPU overlay support patches.
> 
> I think that there's two reasonable overlay manager behaviors,
> depending on the different sorts of systems that might want overlays.
> If the source of the overlay comes from ROM, or from some other
> read-only source, then your patch is clearly right.  If it comes from
> RAM, then some systems may save the overlay (e.g. if it contained
> data) - and thus save the breakpoint.  I can't see any way around this
> unless the overlay manager warns GDB before it unmaps the breakpoint.

Even in the case of read-write overlay sections that were saved by
the overlay manager, "restoring" a breakpoint at the *VMA* in a
non-present overlay would be wrong.  At this memory location, 
some *other* overlay section may already be swapped in, and
the restore would clobber unrelated code (and still leave the
breakpoint instruction in the swapped out backing store).

The way to handle read-write overlay managers is to arrange for
the LMA to point to the backing-store RAM address where the
overlay has been swapped to, and remove the swapped-out breakpoint
at the *LMA* address.  The existing code already handles that
correctly (assuming overlay_events_enabled is false, as it should
be for read-write overlay managers).

Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [rfc] [4/4] SPU overlay support: Bugfix in remove_breakpoint

[Daniel Jacobowitz]

On Fri, May 11, 2007 at 12:05:45AM +0200, Ulrich Weigand wrote:
> The way to handle read-write overlay managers is to arrange for
> the LMA to point to the backing-store RAM address where the
> overlay has been swapped to, and remove the swapped-out breakpoint
> at the *LMA* address.  The existing code already handles that
> correctly (assuming overlay_events_enabled is false, as it should
> be for read-write overlay managers).

I followed you right up until the end.  Why should
overlay_events_enabled be false for read-write overlay management?

We could still be using hardware breakpoints (for example) with
RAM-based overlays.  We'd want notification events so that we could
enable or disable the hardware breakpoint appropriately.

-- 
Daniel Jacobowitz
CodeSourcery

Re: [rfc] [4/4] SPU overlay support: Bugfix in remove_breakpoint

[Ulrich Weigand]

Daniel Jacobowitz wrote:
> On Fri, May 11, 2007 at 12:05:45AM +0200, Ulrich Weigand wrote:
> > The way to handle read-write overlay managers is to arrange for
> > the LMA to point to the backing-store RAM address where the
> > overlay has been swapped to, and remove the swapped-out breakpoint
> > at the *LMA* address.  The existing code already handles that
> > correctly (assuming overlay_events_enabled is false, as it should
> > be for read-write overlay managers).
> 
> I followed you right up until the end.  Why should
> overlay_events_enabled be false for read-write overlay management?
> 
> We could still be using hardware breakpoints (for example) with
> RAM-based overlays.  We'd want notification events so that we could
> enable or disable the hardware breakpoint appropriately.

OK, I didn't consider that case.  Well, that's not supported right
now -- common code does not actually *know* whether the overlay
manager is read-only or read-write, it simply infers that from
whether or not we have event notification.

If we want to support read-write overlays with both hardware and
software breakpoints, we'd need to make common code aware that
the target does support writing to the breakpoint LMA, and
handle software breakpoint as follows:

 - To install, always set breakpoint at the LMA; and if mapped,
   set it also at the VMA.

 - To remove, always remove breakpoint at the LMA; and if
   mapped, remove it also at the VMA.

In any case, removing a software breakpoint at the VMA in
an unmapped section would still be wrong ...


I guess we can implement that once we have a target that actually
supports this particular overlay mode.


Bye,
Ulrich

-- 
  Dr. Ulrich Weigand
  GNU Toolchain for Linux on System z and Cell BE
  Ulrich.Weigand@de.ibm.com

Re: [rfc] [4/4] SPU overlay support: Bugfix in remove_breakpoint

[Daniel Jacobowitz]

On Fri, May 11, 2007 at 08:55:08PM +0200, Ulrich Weigand wrote:
> I guess we can implement that once we have a target that actually
> supports this particular overlay mode.

Fine with me.  Since you have what seems to be the only actively
maintained toolchain using the overlay support, we do it whatever way
is more convenient for SPU until we need the generality :-)

-- 
Daniel Jacobowitz
CodeSourcery