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] |
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.
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?
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |