[Dwarf-discuss] Interpretation of FBREG: implied deref of frame_base?

[Chris Quenelle]

Daniel Jacobowitz wrote:
> On Thu, Apr 21, 2005 at 02:50:24PM -0400, Ron 603-884-2088 wrote:
> 
>>I propose the following replacement:
>>
>>    A subroutine or entry point may also have a DW_AT_frame_base
>>    attribute, whose value is a location description. Evaluation
>>    of that location description computes the "frame base"
>>    address, which can serve as a base pointer for accessing
>>    locations in the frame of that subroutine or entry. In the
>>    special case that the location expression is one of the
>>    register name operators (see Section 2.5.1), the given
>>    register is implicitly dereferenced to obtain the contents
>>    of the register.
> 
> 
> You're propogating the use of "dereference" to express what happens
> here, and I don't think it's a good term.  Here's an example of why:


I agree.  From a terminology point of view using the word "dereference"
here is confusing.


> 
> 
>>    <i>For example, for the DW_AT_frame_base attribute (and
>>    only that attribute) the location expression DW_OP_reg7
>>    is equivalent to either of the expressions
>>    <b>DW_OP_reg7 DW_OP_deref</b> or <b>DW_OP_breg7 0</b></i>.
> 
> 
> I would interpret DW_OP_reg7 DW_OP_deref as "take the _contents_ of
> reg7 and dereference that".  Or else just as nonsensical.
> 
> Basically, in the top level of a location description, DW_OP_reg7
> refers to the location that is a register.  But inside expression
> evaluation, the only meaningful interpretation is the contents of the
> register.

Another bit of a ramble here.  I wrote this email at the same
time that I was trying to wrap my head around this problem.
There might be some benefit to others in seeing my train
of thought.  If not, feel free to ignore me.  ;-)

-----------------

I'm having a lot of trouble wrapping my head around the difference
between a "location" and a "value".  It seems to me that all
expressions produce values.

1) "DW_OP_reg7" always results in the value stored in the register.

2) "DW_OP_addr 0x12341234" always results in the value which is
     the specified address.

Some values are marked with extra semantics of being a "reference" value.
This extra semantics is the tricky spot we're having trouble with.
The debugger knows that the value resulting from 2) must be further
dereferenced (using size information from another spot!) to find
the current contents of a user variable (like a structure maybe).

The value resulting from 1) results in the value of a user
variable without the extra "reference" semantics attached to it.

In my opinion it would have been better to encode this distinction
in the attribute.

DW_AT_location should always take an expression which calculates a
machine address.
DW_AT_value_expr (or something like that) should use an expression to
calculate the actual value of a variable.
DW_AT_frame_base should act like DW_AT_value_expr.

There is no reason make something as complicated as expressions even more
complicated by trying to *imply* special semantics for some kinds of expressions
depending on how they are used.

If you say that DW_OP_reg7 "names" a register, then DW_OP_plus must
take arguments that can be either values *or* "names" of registers.
That seems unnecessarily complicated.

 From the point of view of a debugger, it seems beneficial to know
before evaluating the expression whether I was going to get
a machine address result (which would need further processing)
or an immediate value results (which would need completely different
kind of processing).

For an address, I have to find the size information, and read the
block of data from memory.

For a register value, I have to find the size of the register, find
the size of the data type, and decide if I have to mask the value or not.


--chris