From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5466 invoked by alias); 25 Mar 2008 05:44:04 -0000 Received: (qmail 5457 invoked by uid 22791); 25 Mar 2008 05:44:04 -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; Tue, 25 Mar 2008 05:43:35 +0000 Received: (qmail 7880 invoked from network); 25 Mar 2008 05:43:32 -0000 Received: from unknown (HELO localhost) (vladimir@127.0.0.2) by mail.codesourcery.com with ESMTPA; 25 Mar 2008 05:43:32 -0000 From: Vladimir Prus To: Nick Roberts Subject: Re: per-thread variable objects Date: Tue, 25 Mar 2008 05:44:00 -0000 User-Agent: KMail/1.9.6 (enterprise 0.20070907.709405) Cc: gdb-patches@sources.redhat.com References: <200803242046.07322.vladimir@codesourcery.com> <18408.5672.791817.808097@kahikatea.snap.net.nz> In-Reply-To: <18408.5672.791817.808097@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: <200803250843.25492.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-03/txt/msg00379.txt.bz2 On Monday 24 March 2008 23:59:20 Nick Roberts wrote: > > I've checked it the following revision of Nick's previous > > patch (http://permalink.gmane.org/gmane.comp.gdb.devel/22707) that > > makes variable object remember the thread they belong to. > > I've tested this manually, proper thread and docs will be following > > shortly. > > > > Nick, > > the changes I've made are as follows: > > > > - I use the valid_block instead of special -2 value > > to check if a varobj is global. > > - I did not use -1 value to indicate the thread is gone. Presently, > > we don't specifically mark variables object whose frame is gone, > > and I don't see why we should be do differently for threads. > > > > If something seems wrong, please say. > > It would be nice to reach an agreement before the changes are commmitted. You are right; I apologise for rushing to cross an item from my todo list. > > Index: gdb/ChangeLog > > =================================================================== > > RCS file: /cvs/src/src/gdb/ChangeLog,v > > retrieving revision 1.9247 > > diff -u -p -r1.9247 ChangeLog > > --- gdb/ChangeLog 23 Mar 2008 17:29:32 -0000 1.9247 > > +++ gdb/ChangeLog 24 Mar 2008 17:31:09 -0000 > > @@ -1,3 +1,15 @@ > >... > > I think ChangeLog entries shouldn't be presented as diffs. Does that cause any practical issue to anybody? > >... > > +/* If frame associated with VAR can be found, switch > > + to it and return 1. Otherwise, return 0. */ > > It's not enough for a frame to be found, the pc also has to have an address > value within the valid block. This is one reason why, for such small > functions, I would rather the code spoke for itself. To be honest, the checking for block boundaries cries for comments too. It's not really appparent why we check for it, and importantly -- should variables not in the current block be reported as "out of scope", or reported in some other way. - Volodya