From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23088 invoked by alias); 5 Jun 2003 15:50:13 -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 22932 invoked from network); 5 Jun 2003 15:50:10 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.131) by sources.redhat.com with SMTP; 5 Jun 2003 15:50:10 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id 730862B2F; Thu, 5 Jun 2003 11:50:00 -0400 (EDT) Message-ID: <3EDF66A8.4030003@redhat.com> Date: Thu, 05 Jun 2003 15:50: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> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-06/txt/msg00068.txt.bz2 > 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. >> In fact, I'm even wondering if GDB should always be setting it to >> lval_reg_frame_relative, consider the following: >> >> (gdb) b main >> Breakpoint 1 at 0x1802f84: file gdb.c, line 30. >> (gdb) run >> Starting program: gdb >> Breakpoint 1, main (argc=1, argv=0x7fffe434) at >> /home/scratch/GDB/src/gdb/gdb.c:30 >> 30 memset (&args, 0, sizeof args); >> (gdb) n >> 31 args.argc = argc; >> (gdb) >> 32 args.argv = argv; >> (gdb) print args >> $1 = {argc = 1, argv = 0x0, use_windows = 0, interpreter_p = 0x0} >> >> At this point $1 contains not just args value but also it's location. >> Modify the target state ... >> >> (gdb) n >> 33 args.use_windows = 0; >> (gdb) print args >> $2 = {argc = 1, argv = 0x7fffe434, use_windows = 0, interpreter_p = 0x0} >> (gdb) print $1 >> $3 = {argc = 1, argv = 0x0, use_windows = 0, interpreter_p = 0x0} > > > Agh! That's not right at all! Although I'm not entirely clear on why > it moved? The ``print $1''? That output is correct. GDB saves the value so that it can be refered back to later without having it change. > 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.... Andrew