Re: Use of lval_register?

[Daniel Jacobowitz <drow@mvista.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