From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31446 invoked by alias); 22 Mar 2008 00:33:33 -0000 Received: (qmail 31437 invoked by uid 22791); 22 Mar 2008 00:33:32 -0000 X-Spam-Check-By: sourceware.org Received: from viper.snap.net.nz (HELO viper.snap.net.nz) (202.37.101.8) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 22 Mar 2008 00:33:00 +0000 Received: from kahikatea.snap.net.nz (151.31.255.123.static.snap.net.nz [123.255.31.151]) by viper.snap.net.nz (Postfix) with ESMTP id AA9053DA6A8; Sat, 22 Mar 2008 13:32:57 +1300 (NZDT) Received: by kahikatea.snap.net.nz (Postfix, from userid 1000) id AA21B8FC6D; Sat, 22 Mar 2008 12:32:55 +1200 (NZST) From: Nick Roberts MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <18404.21429.467420.339546@kahikatea.snap.net.nz> Date: Sun, 23 Mar 2008 04:41:00 -0000 To: Vladimir Prus Cc: gdb@sources.redhat.com Subject: Re: MI non-stop mode spec In-Reply-To: <200803211307.50963.vladimir@codesourcery.com> References: <200803190016.02072.vladimir@codesourcery.com> <200803210858.01200.vladimir@codesourcery.com> <18403.33887.752127.140905@kahikatea.snap.net.nz> <200803211307.50963.vladimir@codesourcery.com> X-Mailer: VM 7.19 under Emacs 22.1.92.2 X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2008-03/txt/msg00193.txt.bz2 > > > Didn't you check in a patch to make *-varobjs be found to a > > > thread? > > > > I submitted a patch earlier this year that stopped thinking that a > > variable object had gone out of scope if the thread changed but > > nothing happened. > > Can you resend the current version of that patch, and I'll take a look. I used pid_to_thread_id (inferior_ptid) for the thread_id, just as infrun.c does for *stopped. I think that the thread_id problem for single/multi-threaded programs should be fixed first (perhaps along the lines Daniel suggested). > > Also GDB loses sense of the selected frame: if you change to a > > different thread and back again you always get back to the innermost > > (= current) frame. So that makes it difficult to get > > USE_SELECTED_FRAME to work in the multi-threaded case. > > I think that the syntax mentioned above will get around that. When > GDB evaluates > > -var-update --thread 2 --frame 5 @ > > it switches to thread (which selects frame 0) and then immediately > selects frame 5, so by the time we evaluate expression, we're > in the right thread and frame. Perhaps we're miscommunicating. I mean if the user wants the variable object to "float" with the selected frame, he can't change threads because GDB will forget which frame was the selected frame. In other words, I think that, in a stateful GDB, get_selected_frame needs to be fixed. -- Nick http://www.inet.net.nz/~nickrob