This is the mail archive of the
mailing list for the Archer project.
Re: Q: who maintains the STOPPED/RUNNING state?
- From: Oleg Nesterov <oleg at redhat dot com>
- To: "Frank Ch. Eigler" <fche at redhat dot com>
- Cc: archer at sourceware dot org, Roland McGrath <roland at redhat dot com>
- Date: Wed, 21 Jul 2010 12:18:26 +0200
- Subject: Re: Q: who maintains the STOPPED/RUNNING state?
- References: <20100716205147.GA26313@redhat.com> <20100720144119.GA20580@redhat.com> <firstname.lastname@example.org>
On 07/20, Frank Ch. Eigler wrote:
> Oleg Nesterov <oleg-H+wXaHxf7aLQT0dZR+AlfA@public.gmane.org> writes:
> > [...]
> > 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?
> Even if the protocol documentation theoretically permits this,
> if actual gdb does not send it, and actual gdbserver does not
> specifically handle it, you don't have to worry about it.
I'd like to know how can I check that gdb can't do this.
OK, it seems to be true, so I'll assume ugdb should return E01.
> > - reply E01 because it is not stopped?
> > - stop it, read the regs, reply ?
> > - stop, read the regs, reply, then resume it again ?
> I'm pretty sure that even if this packet is legitimate in this
> context, gdbserver will not stop the target thread just to pull out a
> sample of its registers. The values would become invalid the moment
> the thread resumed anyway.
Oh. Sure, but I used this scenario only to illustrate the question.
> > 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? [...]
> (Whatever gdbserver uses it to mean.)
Nice. OK, unless I misread the (non-trivial) sources, gdbserver doesn't
stop the tracee. It merely sets general_thread, set_desired_inferior()
just sets current_inferior in this case.
> > To clarify, I am mostly asking about the protocol in general, not
> > about the current implementation in gdb.
> The abstract protocol is not precise enough or well-documented enough
> to answer these questions.
Thanks, I knew this from the very beginning ;)
> Reference to actual practice is usually
> required to implement the normal cases.
IOW, RTFS. Understand.
Yes, I tried to avoid the questions. Until I hit the limitations and
As for '$g' in particular... I didn't verify this, but looking at the
sources I strongly believe gdbserver is buggy.
It doesn't check the state of the tracee at all. Usually this doesn't
matter, because (I think) gdb will never send '$g' unless the tracee is
stopped. And if it is stopped, registers should be already cached in
thread_info->regcache_data, gdbserver does fetch_inferior_registers()
in advance when the tracee stops, before gdb actually asks.
However, if gdb sends '$g' when the tracee is not stopped, or if
get_thread_regcache() races with SIGKILL we have the (minor) problems.
regsets_fetch_inferior_registers() will notice that ptrace() fails
and it will complain via perror(), but that is all. It will send the
wrong regcache->registers content to gdb instead of E01.
OK. To answer my question, I think that ugdb can assume that the tracee
must be always stopped by debugger. Unless gdb asks to stop it, of