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

["Ulrich Weigand" <uweigand@de.ibm.com>]

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