Re: Use of lval_register?

[Daniel Jacobowitz <drow@mvista.com>]

On Thu, Jun 05, 2003 at 11:50:00AM -0400, Andrew Cagney wrote:
> 
> >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.

Oh right.  So the value is coming from the cache.

> >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....

I think it should update the cached copy.  I'm not so sure it should
update the in-memory copy, if the var has moved.  That would require
re-evaluating the expression that produced $1 wouldn't it?

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer