New breakpoint_re_set call vs remote targets
Doug Evans
dje@google.com
Thu Jun 25 16:52:00 GMT 2009
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.
More information about the Gdb
mailing list