Re: gdb-serial: inform gdb that target has changed

[Michael Snyder <msnyder at vmware dot com>]

Jakob Engblom wrote:
> Hi!
>
> While looking over gdb7 and getting our tool to work with it, we realized we
> still have an old outstanding issue with gdb-serial and using gdb as a debugger
> frontend. It is the fact that gdb assumes that it is in control, and the target
> cannot tell gdb to refresh its state since the target has changed outside of
> gdb's control.  Today we do the work-around of disconnecting and connecting the
> connection to force gdb to refresh, which is not particularly elegant.
>
> Example cases: with reverse execution and a user on the back-end side jumping to
> back-end bookmarks in time, or triggering breakpoints on hardware accesses or
> other events that gdb have no real idea of. 

Hi Jakob,

I'd like to know more about the context, but my first suggestion
is probably going to be the same in any event -- have you tried
this command instead of disconnect?

    (gdb) help flushregs
    Force gdb to flush its register cache (maintainer command)


After this command, if you give "frame", or any other command
that causes gdb to need to know where the target is, gdb will
fetch the registers afresh.

Now as to your context, and my questions...

Is this something that is happening when gdb is "at the prompt"?

Of course, in normal (sync) mode, gdb assumes that nothing is
happening on the target while we sit at the gdb prompt.

Just for understanding...