This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Use of lval_register?
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Andrew Cagney <ac131313 at redhat dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Thu, 5 Jun 2003 11:17:51 -0400
- Subject: Re: Use of lval_register?
- References: <3EDF5520.8030009@redhat.com>
On Thu, Jun 05, 2003 at 10:35:12AM -0400, Andrew Cagney wrote:
> 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.
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.
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.
> 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?
I guess the question is, what _should_ happen if a variable moves?
e.g. we switch to a different item on its location list.
--
Daniel Jacobowitz
MontaVista Software Debian GNU/Linux Developer