Use of lval_register?

Use of lval_register?

[Andrew Cagney]

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.

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}

Now, presumably the following (I'm still getting over the shock of what 
it did) ...

(gdb) set $1.argc = 2
(gdb) print $1
$4 = {argc = 1, argv = 0x0, use_windows = 0, interpreter_p = 0x0}
(gdb) print args
$5 = {argc = 2, argv = 0x7fffe434, use_windows = 0, interpreter_p = 0x0}

needs to find the current location of args and that means, when args is 
in a register in frame foo, potentially having to re-find where those 
registers are now saved.

(please lets ignore the possible need to attach a scope breakpoint to 
the variable so that it knows that the value has gone out of scope ...).

Andrew

PS: I should note that my first attempt at doing this it didn't work. 
On the MIPS, GDB was having trouble re-finding the frame but I'll 
attribute that to the codes use of VALUE_FRAME + get_frame_base() 
instead of VALUE_FRAME_ID + get_frame_id() :-^

PPS: The above also has a bug.  When reg_store, VALUE_REGNUM is probably 
wrong.  It should be REALNUM (returned by frame_register_unwind) which 
is REGNUM's real location.

Re: Use of lval_register?

[Daniel Jacobowitz]

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

Re: 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

Re: Use of lval_register?

[Daniel Jacobowitz]

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

Re: Use of lval_register?

[Andrew Cagney]

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

Actually, these are separate but related problems:

- a location expression determines that a value is in REGNUM N in FRAME F.

- the CFI then determines that REGNUM N in frame F is actually in REGNUM 
M in frame G.

Printing a variable relies on both mechanisms, printing $r1 uses just 
the first.

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

It's comming from GDB's infinite value history pool (the word cache 
suggests that it is eventually flushed, which it isn't :-).

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

Eventually.  For the moment I'm just worred about getting it to 
re-evaluate the registers the value is assumed to reside in.

Or should it only modify the history pool (modifying memory is weird 
here, but where to draw the line is also weird).

Andrew

Re: Use of lval_register?

[Daniel Jacobowitz]

On Thu, Jun 05, 2003 at 12:12:50PM -0400, Andrew Cagney wrote:
> >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.
> 
> Actually, these are separate but related problems:
> 
> - a location expression determines that a value is in REGNUM N in FRAME F.
> 
> - the CFI then determines that REGNUM N in frame F is actually in REGNUM 
> M in frame G.
> 
> Printing a variable relies on both mechanisms, printing $r1 uses just 
> the first.
> 
> >>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.
> 
> It's comming from GDB's infinite value history pool (the word cache 
> suggests that it is eventually flushed, which it isn't :-).
> 
> >
> >
> >>>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?
> 
> Eventually.  For the moment I'm just worred about getting it to 
> re-evaluate the registers the value is assumed to reside in.
> 
> Or should it only modify the history pool (modifying memory is weird 
> here, but where to draw the line is also weird).

After some more thought, I suppose it should modify both the pool and
memory.  It's just not clear how to find out where in memory it should
be, now...

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: Use of lval_register?

[Andrew Cagney]

>> >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?
> 
>> 
>> Eventually.  For the moment I'm just worred about getting it to 
>> re-evaluate the registers the value is assumed to reside in.
>> 
>> Or should it only modify the history pool (modifying memory is weird 
>> here, but where to draw the line is also weird).
> 
> 
> After some more thought, I suppose it should modify both the pool and
> memory.  It's just not clear how to find out where in memory it should
> be, now...

Or just modify the pool?

varobj provides a mechanism for modifying / tracking values in the target.

Andrew

Re: Use of lval_register?

[Daniel Jacobowitz]

On Thu, Jun 05, 2003 at 01:48:45PM -0400, Andrew Cagney wrote:
> 
> >>>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?
> >
> >>
> >>Eventually.  For the moment I'm just worred about getting it to 
> >>re-evaluate the registers the value is assumed to reside in.
> >>
> >>Or should it only modify the history pool (modifying memory is weird 
> >>here, but where to draw the line is also weird).
> >
> >
> >After some more thought, I suppose it should modify both the pool and
> >memory.  It's just not clear how to find out where in memory it should
> >be, now...
> 
> Or just modify the pool?

I'd be pretty surprised by this behavior.  I sometimes use values this
way, to tweak a member of a struct later.  If we're only going to
change the copy in the pool then I suspect we should refuse to allow
changes at all, if we can't change the program's copy.

> varobj provides a mechanism for modifying / tracking values in the target.

Hmm.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer