From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15489 invoked by alias); 11 Jul 2008 19:07:47 -0000 Received: (qmail 15480 invoked by uid 22791); 11 Jul 2008 19:07:47 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 11 Jul 2008 19:07:29 +0000 Received: (qmail 22182 invoked from network); 11 Jul 2008 19:07:28 -0000 Received: from unknown (HELO 172.16.unknown.plus.ru) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 11 Jul 2008 19:07:28 -0000 From: Vladimir Prus To: gdb-patches@sources.redhat.com Subject: Re: [MI non-stop 10/11] Skip varobj in running threads. Date: Fri, 11 Jul 2008 19:07:00 -0000 User-Agent: KMail/1.9.9 References: <200806282100.06214.vladimir@codesourcery.com> <20080711135335.GF2651@caradoc.them.org> In-Reply-To: <20080711135335.GF2651@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200807112307.26477.vladimir@codesourcery.com> Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-07/txt/msg00222.txt.bz2 On Friday 11 July 2008 17:53:35 Daniel Jacobowitz wrote: > On Sat, Jun 28, 2008 at 09:00:06PM +0400, Vladimir Prus wrote: > > > > If a variable object is bound to a specific thread, and we're doing > > > > -var-update * > > > > and varobj's thread is running, we cannot update varobj -- so we skip it. > > Will commit when core non-stop is in. > > I think this needs to go in the manual. Would it be helpful to > indicate to the front end that a variable could not be updated due to > a running thread? Possibly -- the frontend may want to decorate varobj from running threads in specific ways. OTOH, until non-stop frontends actually appear, we don't know exact requirements, so I'd prefer to introduce bare minimum -- which is not falling over trying evaluate expressions in running threads. > If a varobj is bound to a particular thread that usually means it's > bound to a particular frame, right? Yes. Assuming non-always-a-thread targets do not exist, varobj is bound to a particular thread if and only if it's bound to some frame. > In which case reading it while > the target is running doesn't make (much) sense, so there's nothing > target specific about this. Right. Even if target can technically access memory of a running thread, there's no way to evaluate such a varobj since we don't have no stack. > > + if (thread_id == 0 && is_executing (inferior_ptid)) > > + thread_running = 1; > > + else if (thread_id > 0) > > + { > > + struct thread_info *tp = find_thread_id (thread_id); > > + if (tp) > > + thread_running = is_running (tp->ptid); > > + } > > Why is_running in one place and is_executing in the other? It's a mistake, should be is_running. > Should we try reading from something besides inferior_ptid for unbound > varobjs? The current MI/non-stop design assumes that commands are executed in a specific thread. If it's running, and command needs to access target, we get an error. This is more predictable than picking random thread. Some targets, like break, can implicitly use the current frame, and switching to random thread will make them behave erratically. - Volodya