Re: other weird gdb-mi problems

[Dmitry Dzhus]

Nick Roberts wrote:

> It's an Emacs problem.  The CLI commands "up" and "down", don't emit any
> GDB/MI notifications so Emacs doen't know that the display needs updating.

I've changed `gdb-mi.el` to append `--frame` and `--thread` options to
every command it sends to GDB. This is is the recommended way to use
GDB/MI, because we can put all frame/thread selection logic to
frontend-land completely, without relying on internal state of GDB.
That's the way `gdb-mi.el` works now — select frame/thread on frontend
side and append --thread/--frame appropriately. `gdb-thread-number` and
`gdb-frame-number` variables reflect current thread (probably
buffer-local) and frame selected by Emacs.

When we type `thread N` in GUD console, GDB emits
`=thread-selected,id=N` notification. Emacs reads this and changes
`gdb-thread-number`.

No such notification is provided when we type `frame M`, `up` or `down`.
As the result, Emacs can't notice the change of current frame.

Previously `gdb-mi.el` deducted current frame from internal state of
GDB. I can revert changes to follow this behaviour again, but the real
fix would involve implementing `=frame-selected` notification in GDB.

> http://sourceware.org/ml/gdb-patches/2008-04/msg00377.html but there hasn't
> been much interest.

It's pity that these patches didn't make it to GDB upstream :( I see now
that current `=thread-selected` notification implementation in GDB uses
a different and perhaps less elegant approach. I've posted a patch to
GDB mailing list which adds =frame-selected notification following the
current approach. I hope that GDB upstream accepts the patch or
reevaluates the one you'd sent before.
-- 
Happy Hacking.

http://sphinx.net.ru
む