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

["Ulrich Weigand" <uweigand at de dot ibm dot com>]

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