Use of lval_register?

[Andrew Cagney]

> 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