This is the mail archive of the mailing list for the elfutils 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: Dwarf_Op

On Wed, May 08, 2019 at 06:03:55PM +0000, Sasha Da Rocha Pinheiro wrote:
> About the *ops returned from dwarf_frame_register():
> Is it correct to say that if we don't get a DW_OP_stack_value as the
> last operation, the value on top of the stack will always be a
> memory address? Meaning you must dereference it? Even though there
> is no DW_OP_deref provided as last operation? If not, what else
> could it be?

There could be no operations at all, an empty location description,
then there simply is no location/value. It could be a single register
location description operation (DW_OP_reg[0..31] or DW_OP_regx) that
says the value is in that particular register (note this is different
from the DW_OP_bregx operations which pushes the contents of the
register on the expression stack). Or it is one or more of the other
operations which leave the location (an address) on the expression
stack. If the last operation is DW_OP_stack_value then the value on
the top of the expression stack is the value itself (and not a
location where the value can be changed).

Technically it can also be an DW_OP_implicit_value (again a value, not
a location), and DW_OP_implicit_pointer (a "fake" pointer/location,
but really a description of the value of that location), or a
composite location description (DW_OP_[bit_]piece, multiple location
descriptions that have to be combined to get the value). But these
don't come from dwarf_frame_register at the moment.

> Another issue: I am trying to decode the following *ops:
> DW_OP_call_frame_cfa DW_OP_stack_value This was returned after I
> requested register 31 (SP in aarch64) at address 0x40091c.  As you
> can see below, I pasted the CIE and FDE relative to this address
> using eu-readelf and dwarfdump.  Is it that, in this case,
> DW_OP_call_frame_cfa means "get the CFA value at 0x00400918"? Why
> isn't SP rule undefined or same_value, instead of those two
> operations?

Yes, that looks circular, but it is meant to be "efficient". Often
registers can be found at an offset of the current CFA (or in this
case, it is the CFA value). You get the CFA for a frame with
dwarf_frame_cfa (), which works similar to dwarf_frame_register (),
the CFA itself doesn't have/is a register number however.

Hope that helps,


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