From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29251 invoked by alias); 22 Mar 2008 17:33:38 -0000 Received: (qmail 29240 invoked by uid 22791); 22 Mar 2008 17:33:38 -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; Sat, 22 Mar 2008 17:33:07 +0000 Received: (qmail 17536 invoked from network); 22 Mar 2008 17:33:03 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 22 Mar 2008 17:33:03 -0000 From: Vladimir Prus To: Nick Roberts Subject: Re: MI non-stop mode spec Date: Sun, 23 Mar 2008 05:18:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: gdb@sources.redhat.com References: <200803190016.02072.vladimir@codesourcery.com> <200803211307.50963.vladimir@codesourcery.com> <18404.21429.467420.339546@kahikatea.snap.net.nz> In-Reply-To: <18404.21429.467420.339546@kahikatea.snap.net.nz> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200803222033.11760.vladimir@codesourcery.com> 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/msg00194.txt.bz2 On Saturday 22 March 2008 03:32:53 Nick Roberts wrote: > > > > 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). Dan's patch is in, however, it only affects Linux. I suspect in might be a long time till the problem is solved on all system. Until then, we probably should assume that if thread list is empty, then the program is ST and never will become MT. I happen to be working on variable objects for non-stop now, so I'll play with the last version of your patch that you have posted. > > > 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. Maybe we're looking at it from different perspectives. I think that frontend can, and probably should, maintain its own notion of selected frame for each thread. Then, the @ variables can be re-evaluated in whatever thread/frame is current from frontend point of view. - Volodya