This is the mail archive of the archer@sourceware.org mailing list for the Archer project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Q: who maintains the STOPPED/RUNNING state?


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:

	`qC'
	     Return the current thread ID.

	     Reply:
	    `QC 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" ?

And,

	    `(anything else)'
		  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.

Oleg.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]