This is the mail archive of the gdb@sources.redhat.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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.

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



Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]