This is the mail archive of the
mailing list for the Archer project.
Q: who maintains the STOPPED/RUNNING state?
- From: Oleg Nesterov <oleg at redhat dot com>
- To: archer at sourceware dot org
- Cc: Roland McGrath <roland at redhat dot com>
- Date: Tue, 20 Jul 2010 16:41:19 +0200
- Subject: Q: who maintains the STOPPED/RUNNING state?
- References: <20100716205147.GA26313@redhat.com>
To simplify, let's consider the simple case. gdb attaches to the
single-threaded process which can never exit. To simplify again, it
can be either RUNNING (gdb sent '$c') or STOPPED (say, gdb sends ^C).
Who maintains this state? gdb, server, both? To illustrate, suppose
that ugdb receives
$c <--- resumes the tracee
$g <--- asks general registers
What should ugdb do?
- reply E01 because it is not stopped?
- stop it, read the regs, reply ?
- stop, read the regs, reply, then resume it again ?
This is connected to another question. From gdb.info:
`H C THREAD-ID'
Set thread for subsequent operations (`m', `M', `g', `G', et.al.).
What does this "Set" above actually mean? Does it mean "stop this
thread" as well?
Unrelated question. From gdb.info:
Return the current thread ID.
Cough. I simply can't understand what is the "current thread" in
general. Perhaps, "current thread" == "the last thread selected
by Hg, or the last thead which reported something like T05:thread" ?
Any other reply implies the old thread ID.
This looks even more confusing. What is the "old thread" ?
To clarify, I am mostly asking about the protocol in general,
not about the current implementation in gdb.