[RFC] gdb/674: GDB/MI No way to know the current selected thread (fwd))

Keith Seitz keiths@redhat.com
Wed Aug 28 09:40:00 GMT 2002


On Wed, 28 Aug 2002, Keith Seitz wrote:

> Well, it could be an event, but like selected-frame, the UI will still 
> need a way to get the currently selected thread. Actually, the same 
> problem really exists for stack frames, too, but it is mitigated by the 
> fact that the UI can assume that whenever the target has executed, it is 
> at stack depth 0. Unfortunately, the same is not true for threads. The 
> thread numbers are "random" as far as the UI is concerned.

I've looked at this problem a little on my interpreter branch, and I've 
discovered that this problem is already solved, in multiple places:

(gdb)
-break-insert main
=breakpoint-create,number="1"
^done
(gdb)
-exec-run
^running
(gdb)
[snip]
~"[New Thread 1024 (LWP 3062)]\n"
[snip]
=context-changed,thread="1"
~"[Switching to Thread 1024 (LWP 3062)]\n"
*stopped,reason="breakpoint-hit",bkptno="1",thread-id="1",frame={addr="0x08048556",func="main",args=[{name="argc",value="1"},{name="argv",value="0xbfffdc84"}],file="main.c",line="17"}
(gdb) 

Note the "=context-changed" line and the "thread-id" parameter in the 
result.

The event comes from one of Apple's changes, which I morphed into an event 
on the branch, but as you can see, the info is there already in the stop 
result/reason.

So now I'm not sure that this particular notification is absolutely 
necessary anymore (maybe async?), even though Apple had something in 
place. Maybe Jim can comment why it was needed? (Maybe is misunderstood 
what Apple was doing with the context_hook?)

Anyway, it seems that this PR has a simple answer: track the selected 
thread via the stop result (and context_changed event messages from the 
console).

Keith



More information about the Gdb mailing list