This is the mail archive of the 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

	     Set thread for subsequent operations (`m', `M', `g', `G',

What does this "Set" above actually mean? Does it mean "stop this
thread" as well?

Unrelated question. From

	     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" ?


	    `(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.


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