Re: New breakpoint_re_set call vs remote targets

[Daniel Jacobowitz <drow@false.org>]

On Thu, Jun 25, 2009 at 12:37:16AM +0100, Pedro Alves wrote:
> What does the failure look like?  I assume that either prologue
> skipping just doesn't skip anything meaningful and the breakpoint
> ends up set at the beginning of the garbage "prologue"; or, some exception
> is thrown (I'd argue that prologue skipping shouldn't throw in this case).

The memory happens to be mostly zero at this point.  The zero pattern
in Thumb mode is lsl r0, #0 (from memory, don't shoot me if I'm
wrong).  That's a nop - which the prologue skipper happily skips.
In fact, in one case it keeps skipping right past the end of the
function.

(This is nodebug.exp.)

> This sounds like something that has always been broken, but we
> didn't notice due to the fact that nothing happens pulls symbols
> between "target remote" and "load" on those configurations: e.g.,
> from your description, target remote; add-symbol-file; load;
> should be failing even before that patch? (given that add-symbol-file
> triggers a breakpoint reset).

Probably so, but in practice it rarely ever triggered before now.
Now it happens all the time, although it's mitigated by debug info;
we'll use that for prologue skipping instead.

> Yeah, this could hacked by forcing trust-readonly-sections in
> some places.  This and address spaces have made me think before that
> to_xfer_partial may be a too stiff interface for memory reads
> (in that we may end up reviving deprecated_xfer_memory...).
> 
> > and (B) I'm not 
> > sure if we want to handle fix-and-continue style function patching in
> > which case we need to read from the target anyway.
> 
> Right.  That's the main counter-point.

Curious what folks think of the tradeoff here.

> > Thoughts?  Any other approaches to fix this failure?
> 
> Assuming the debugging session didn't blow up, wouldn't a
> breakpoint_re_set call after loading fix this?  The live
> target has gotten new code loaded, so triggering
> breakpoint re-evaluation and prologue skipping doesn't sound
> wrong to me.

Yeah, that would probably do it.  I think it's wacky that prologue
skipping relies on target memory, though.

> It also occurs to me that for always-inserted mode, we'd probably
> want to uninsert breakpoints before loading.

Uck.

-- 
Daniel Jacobowitz
CodeSourcery