From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24884 invoked by alias); 5 Jun 2003 14:35:24 -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 24842 invoked from network); 5 Jun 2003 14:35:24 -0000 Received: from unknown (HELO localhost.redhat.com) (207.219.125.131) by sources.redhat.com with SMTP; 5 Jun 2003 14:35:24 -0000 Received: from redhat.com (localhost [127.0.0.1]) by localhost.redhat.com (Postfix) with ESMTP id DA3092B2F for ; Thu, 5 Jun 2003 10:35:12 -0400 (EDT) Message-ID: <3EDF5520.8030009@redhat.com> Date: Thu, 05 Jun 2003 14:35: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: gdb@sources.redhat.com Subject: Use of lval_register? Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-06/txt/msg00065.txt.bz2 Um, so ok humor me here. Should value_of_register and value_from_register be using lval_register? "findvar.c:value_from_register" contains the code snipit: VALUE_REGNO (v) = regnum; .... if ((reg_stor && mem_stor) || (mem_stor && !mem_tracking)) /* Mixed storage; all of the hassle we just went through was for some good purpose. */ { VALUE_LVAL (v) = lval_reg_frame_relative; VALUE_FRAME (v) = get_frame_base (frame); VALUE_FRAME_REGNUM (v) = regnum; } else if (mem_stor) { VALUE_LVAL (v) = lval_memory; VALUE_ADDRESS (v) = first_addr; } else if (reg_stor) { VALUE_LVAL (v) = lval_register; VALUE_ADDRESS (v) = first_addr; } else internal_error (__FILE__, __LINE__, "value_from_register: Value not stored anywhere!"); I'm left wondering why GDB doesn't instead always set the location to lval_reg_frame_relative and be done with it. The other use of lval_register in value of register is similar. 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} Now, presumably the following (I'm still getting over the shock of what it did) ... (gdb) set $1.argc = 2 (gdb) print $1 $4 = {argc = 1, argv = 0x0, use_windows = 0, interpreter_p = 0x0} (gdb) print args $5 = {argc = 2, argv = 0x7fffe434, use_windows = 0, interpreter_p = 0x0} needs to find the current location of args and that means, when args is in a register in frame foo, potentially having to re-find where those registers are now saved. (please lets ignore the possible need to attach a scope breakpoint to the variable so that it knows that the value has gone out of scope ...). Andrew PS: I should note that my first attempt at doing this it didn't work. On the MIPS, GDB was having trouble re-finding the frame but I'll attribute that to the codes use of VALUE_FRAME + get_frame_base() instead of VALUE_FRAME_ID + get_frame_id() :-^ PPS: The above also has a bug. When reg_store, VALUE_REGNUM is probably wrong. It should be REALNUM (returned by frame_register_unwind) which is REGNUM's real location.