From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28433 invoked by alias); 5 Jun 2003 16:13:01 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 28391 invoked from network); 5 Jun 2003 16:13:00 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.131) by sources.redhat.com with SMTP; 5 Jun 2003 16:13:00 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 9C2702B2F; Thu, 5 Jun 2003 12:12:50 -0400 (EDT) Message-ID: <3EDF6C02.90807@redhat.com> Date: Thu, 05 Jun 2003 16:13:00 -0000 From: Andrew Cagney User-Agent: Mozilla/5.0 (X11; U; NetBSD macppc; en-US; rv:1.0.2) Gecko/20030223 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Daniel Jacobowitz Cc: gdb@sources.redhat.com Subject: Re: Use of lval_register? References: <3EDF5520.8030009@redhat.com> <20030605151750.GA25587@nevyn.them.org> <3EDF66A8.4030003@redhat.com> <20030605155851.GA28099@nevyn.them.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-06/txt/msg00070.txt.bz2 > On Thu, Jun 05, 2003 at 11:50:00AM -0400, Andrew Cagney wrote: > >> > >> >lval_reg_frame_relative is a relatively recent addition, I believe, >> >added to fix some particular problem with values stored in two places. >> >Probably around the HP merge? But that's just a guess. > >> >> Ah. >> > >> >I think that lval_reg_frame_relative, lval_memory, and lval_register >> >should all be combined to an lval_location which takes the frame and a >> >description of a location, personally. > >> >> These will all need to live in harmony for a wile though. Actually, these are separate but related problems: - a location expression determines that a value is in REGNUM N in FRAME F. - the CFI then determines that REGNUM N in frame F is actually in REGNUM M in frame G. Printing a variable relies on both mechanisms, printing $r1 uses just the first. >> The ``print $1''? That output is correct. GDB saves the value so that >> it can be refered back to later without having it change. > Oh right. So the value is coming from the cache. It's comming from GDB's infinite value history pool (the word cache suggests that it is eventually flushed, which it isn't :-). > > >> >I guess the question is, what _should_ happen if a variable moves? >> >e.g. we switch to a different item on its location list. > >> >> From the users view point, the variable hasn't moved. Hence the >> assignment: >> >> $1.argc = N >> >> should always work. Should that assignment update the cached $1 value >> as well, hmm.... > > > I think it should update the cached copy. I'm not so sure it should > update the in-memory copy, if the var has moved. That would require > re-evaluating the expression that produced $1 wouldn't it? Eventually. For the moment I'm just worred about getting it to re-evaluate the registers the value is assumed to reside in. Or should it only modify the history pool (modifying memory is weird here, but where to draw the line is also weird). Andrew