Re: New breakpoint_re_set call vs remote targets

[Pedro Alves <pedro at codesourcery dot com>]

On Wednesday 24 June 2009 20:03:46, Daniel Jacobowitz wrote:
> This patch:
> 
> 2009-06-17 ?Pierre Muller ?<muller@ics.u-strasbg.fr>
> ? ? ? ? Pedro Alves ?<pedro@codesourcery.com>
> 
> ? ? ? ? * infcmd.c (post_create_inferior): Call breakpoint_re_set
> ????????after target
> ? ? ? ? is pushed for watchpoint promotion to hardware watchpoint.
> 
> causes a testcase failure in nodebug.exp for arm-none-eabi. ?It will
> affect all bare-metal targets.
> 
> The sequence is "target remote", which calls post_create_inferior
> before any program exists on the remote side. ?Then later "load" fills
> in the code. ?So we're doing prologue skipping - by reading target
> memory - before we've written the code to target memory.

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).

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).

> 
> I have long had a plan to speed up prologue skipping by making it read
> directly from the executable if possible. ?We're using the
> executable's symbol table, so there's no reason to think the prologue
> will have moved around on the target. ?The problems with this approach
> are (A) it involves changing a lot of symbol readers, 

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.

> 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.

But, what was the real failure?

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

-- 
Pedro Alves