From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24069 invoked by alias); 21 Jul 2010 10:20:46 -0000 Mailing-List: contact archer-help@sourceware.org; run by ezmlm Sender: Precedence: bulk List-Post: List-Help: List-Subscribe: List-Id: Received: (qmail 24033 invoked by uid 22791); 21 Jul 2010 10:20:43 -0000 X-SWARE-Spam-Status: No, hits=-6.6 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_HI,SPF_HELO_PASS,TW_EG,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Date: Wed, 21 Jul 2010 10:20:00 -0000 From: Oleg Nesterov To: "Frank Ch. Eigler" Cc: archer@sourceware.org, Roland McGrath Subject: Re: Q: who maintains the STOPPED/RUNNING state? Message-ID: <20100721101826.GA12176@redhat.com> References: <20100716205147.GA26313@redhat.com> <20100720144119.GA20580@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.18 (2008-05-17) X-SW-Source: 2010-q3/txt/msg00054.txt.bz2 On 07/20, Frank Ch. Eigler wrote: > > Oleg Nesterov 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 bugs (threading). 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 course. Oleg.