This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Use of lval_register?
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