Re: Use of lval_register?

[Andrew Cagney <ac131313 at redhat dot com>]

> 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