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