This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: gdb-serial: inform gdb that target has changed
- From: "Jakob Engblom" <jakob at virtutech dot com>
- To: "'Michael Snyder'" <msnyder at vmware dot com>
- Cc: <gdb at sourceware dot org>
- Date: Wed, 28 Oct 2009 11:19:50 +0100
- Subject: RE: gdb-serial: inform gdb that target has changed
- References: <007101ca573c$0dfd9fa0$29f8dee0$@com> <4AE751C8.2070902@vmware.com>
> 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.
We need this to be invoked from the target, across gdb-serial connections.
> 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.
Yes.
Sice Simics has its own parallel command-line, we can be stepping the target,
changing memory and register contents, and do other things as gdb is sitting at
prompt waiting for commands.
So a simple gdb-serial backwards command to notify gdb that the target has
changed and that all state should be updated would be the simple perfect
solution for us.
Best regards,
/jakob
_______________________________________________________
Jakob Engblom, PhD, Technical Marketing Manager
Virtutech?????????????????? Direct: +46 8 690 07 47???
Drottningholmsvägen 22????? Mobile: +46 709 242 646??
11243 Stockholm???????????? Web:??? www.virtutech.com?
Sweden
________________________________________________________
?