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?
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?
=============
dwarfdump output
=============
< 5><0x00400918:0x00400974><main><cie offset 0x000000b4::cie index
0><fde offset 0x000000b0 length: 0x00000024>
<eh aug data len 0x0>
0x00400918: <off cfa=00(r31) >
0x0040091c: <off cfa=32(r31) > <off r29=-32(cfa) > <off r30=-24(cfa) >
0x00400920: <off cfa=32(r29) > <off r29=-32(cfa) > <off r30=-24(cfa) >
0x00400970: <off cfa=00(r31) >
cie:
< 0> version 1
cie section offset 0 0x00000000
augmentation zR
code_alignment_factor 4
data_alignment_factor -8
return_address_register 30
eh aug data len 0x1 bytes 0x1b
bytes of initial instructions 7
cie length 20
initial instructions
0 DW_CFA_def_cfa r31 0
3 DW_CFA_nop
4 DW_CFA_nop
5 DW_CFA_nop
6 DW_CFA_nop
============
eu-readelf output
============
[ 0] CIE length=20
CIE_id: 0
version: 1
augmentation: "zR"
code_alignment_factor: 4
data_alignment_factor: -8
return_address_register: 30
Augmentation data: 0x1b (FDE address encoding: sdata4 pcrel)
Program:
def_cfa r31 (reg31) at offset 0
nop
nop
nop
nop
...
[ b0] FDE length=36 cie=[ 0]
CIE_pointer: 180
initial_location: 0x0000000000400918 <main> (offset: 0x918)
address_range: 0x5c (end offset: 0x974)
Program:
advance_loc 1 to 0x91c
def_cfa_offset 32
offset r29 (reg29) at cfa-32
offset r30 (reg30) at cfa-24
advance_loc 1 to 0x920
def_cfa_register r29 (reg29)
advance_loc 20 to 0x970
restore r30 (reg30)
restore r29 (reg29)
def_cfa r31 (reg31) at offset 0
nop
nop
nop
nop
nop
nop
nop
From: Mark Wielaard <m...@klomp.org>
Sent: Friday, May 3, 2019 4:09 PM
To: Sasha Da Rocha Pinheiro
Cc: elfutils-devel@sourceware.org
Subject: Re: Dwarf_Op
On Thu, May 02, 2019 at 07:29:33PM +0000, Sasha Da Rocha Pinheiro wrote:
> So why not a DW_OP_constu or DW_OP_consts and then a DW_OP_plus?
Probably because that is multiple operators and less efficiently
encoded. But yes, it would be slightly more "correct" semantically.
In this case however it is for computing (unsigned) addresses (CFA
plus offset) in which case unsigned arithmetic is fine.
> About the Dwarf_Op array we get from dwarf_frame_register(), (which
> are a sequence of Dwarf expressions): are they suppose to be an
> abstraction to all types of dwarf location descriptions? Including
> Single (single and composite) and Location Lists?
In theory yes, it is not a special kind of Dwarf Location
Expression. It should be usable generially, although clearly it
resolves in the context of the CFI (current pc and register values,
memory, etc.). It turns the CFI for getting a register into a Dwarf
Location Expression that you can use to resolve the value of that
register.
> Is there more documentation about dwfl? What does dwfl stand for?
> (dwarf frame library?!)
All documentation is in libdwfl.h for now. I am not sure dwfl
officially stands for anything. But if ebl is the Elf Backend
Library, then dwfl could be the libDW Frontend Library.
> We already have access to the process memory space and registers, so
> would expr_eval be suffice?
Yes, if you are just looking for CFI/Unwinding then that should be
enough. But expr_eval isn't a generic DWARF Expression evaluator so
you cannot simply use it as is for generic DWARF Location Expressions
coming from other parts of DWARF.
> In case of finding the registers values at some PC, would it always
> gives us a single expression (like an address or an offset from a
> register)?
Yes.
> In the comment of dwarf_frame_register() in the file libdw.h, there
> is: "Note the last operation is DW_OP_stack_value if there is no
> mutable location but only a computable value." What is a mutable
> location, I didn't find this concept in the Dwarf Debugging
> Information Format v4.
I believe "mutable locations" is what DWARF calls Location
Descriptions, which point to a memory location or register where the
value can be found (and so can be changed in that location). And what
is called a "computable value" is what DWARF calls Implicit Location
Descriptions, which provides a value itself (so there is no real
location that can be changed).
> Also there there is:
>
> 1057 For common simple expressions *OPS is OPS_MEM. For arbitrary DWARF
> 1058 expressions in the CFI, *OPS is an internal pointer that can be used
> as
> 1059 long as the Dwarf_CFI used to create FRAME remains alive. */
>
> Why simple expression can only have 3 operations? (since Dwarf_Op ops_mem[3])
> And what's an arbitrary Dwarf expression? What's a non-arbitrary?
It is "common simple expressions" vs "arbitrary expressions". The
interface is made to make memory management easier (for the
implementation of the function). But might be slightly confusing if
you don't know that (you really shouldn't know about the internals).
The idea is that most often the CFI expression can be turned into 1, 2
or 3 DWARF operators. The caller is asked to provide memory to store
those. If the expression is bigger, then a pointer to internal storage
is returned. In both cases you would just use *OPS for the *NOPS
number of operations (in the first case *OPS points to your *MEM_OPS
provided array, in the second case it points to some internal storage.
Cheers,
Mark
