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

[Todd Allen]

> 
> I think the first paragraph of section 2.5.1, "Register Name
> Operators", spells out some stuff that clarifies all this:
> 
>     The following DWARF operators can be used to name a register.
>     They can be used only in location expressions.  Each register name
>     operator must be used alone (as a DWARF expression consisting of
>     just that one operation).
> 
> and similarly in 2.5.2, "Location Expressions":
> 
>     The location operations fall into two categories, register names
>     and addressing operations.
> 
> In other words, location expressions that are register names are just
> a different kind of beast from other DWARF expressions: they're never
> part of a larger expression (except for DW_OP_piece), and are used to
> describe objects that lack addresses altogether.
> 

By golly, you're right.  And here's a little bit more support from 2.4.1.3:

   The DW_OP_deref operation pops the top stack entry and treats it as an
   address.  The value retrieved from that address is pushed.  ...

I think that actually poses a problem for attributes like DW_AT_data_location
and DW_OP_push_address (and we at Concurrent have a fair number of extensions
that are similar to this except that they have an implicit
DW_OP_push_object_address).

Say you have a hypothetical type whose representation is a pointer to an
8-byte block of memory where the first 4 bytes are a pointer to some metadata
and the second 4 bytes are a pointer to the actual data in the object.  Like
this:

   +--------+     +-----------------+
   | object | --> | ptr to metadata |
   +--------+     +-----------------+     +------+
                  | ptr data data   | --> | data |
                  +-----------------+     | ...  |
                                          +------+

The only reasonable way to describe that would be as follows:

   T:
   DW_TAG_some_type
      DW_AT_data_location  DW_OP_push_object_address
                           DW_OP_deref              
                           DW_OP_plus_uconst 4      
                           DW_OP_deref

And that's just fine if your object is in memory:

   DW_TAG_variable                                              
      DW_AT_name "some_variable"                                
      DW_AT_location DW_OP_addr 0x10000000
      DW_AT_type T

But it makes no sense if your object is in a register:

   DW_TAG_variable                                              
      DW_AT_name "some_variable"                                
      DW_AT_location DW_OP_reg3                                 
      DW_AT_typeT 

Because the DW_OP_push_address pushes the address of the object.  If the is
in a register, it has no address.  So, the above technically is undefined.
Although I think its meaning is clear.  I'd like to see this sort of thing
legitimized.

-- 
Todd Allen
Concurrent Computer Corporation