Re: New breakpoint_re_set call vs remote targets

[Doug Evans <dje at google dot com>]

On Wed, Jun 24, 2009 at 12:03 PM, Daniel Jacobowitz<drow@false.org> 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.

"create_inferior" has a very specific connotation (at least in some
contexts), and at first glance it's odd that target_remote is calling
any foo_create_inferior.  [Consider, for example, that "run" uses
target_create_inferior, to_create_inferior is the target hook for
starting programs, and target remote doesn't support "run".]

The first question I had is why is target remote calling post_create_inferior?

So I go and look at post_create_inferior, which has this:

/* Common actions to take after creating any sort of inferior, by any
     means (running, attaching, connecting, et cetera).  The target
     should be stopped.  */

I wonder if name choices are making things harder than they should be.
[Harder in the sense that bugs get inadvertently introduced, and in
the sense that it's not as straightforward to reason about these
things.]
[Bad timing that this came up yesterday in a different context. :-)]

> 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, 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.
>
> Thoughts? ?Any other approaches to fix this failure?

I wonder if one useful step is to reassess post_create_inferior, and
maybe split it up or something.

From my perhaps ancient point of view, gdb is for debugging two kinds
of programs: hosted and freestanding (to borrow jargon from C - though
non-bare-metal and bare-metal may be more accurate. 1/2 :-)), and I
wonder if they're being inadvertently fused.
Or not.