On Wed, Oct 30, 2019 at 02:23:06PM +0100, Mark Wielaard wrote:
> Hi Omar,
>
> On Mon, 2019-10-07 at 02:05 -0700, Omar Sandoval wrote:
> > libdwfl can evaluate DWARF expressions in order to unwind the stack,
> > but this functionality isn't exposed to clients of the library. Now that
> > the pieces are in place, add dwfl_frame_eval_expr to provide this feature.
>
> I think this is useful. But same issue as the previous patch that I am
> not sure the error handling is correct for state->frame == NULL.
The change I described for the previous patch should fix that.
> Also this could really use some examples and maybe a small testcase.
>
> That would show how to handle DWARF expressions to are simple location
> descriptions (which calculate a location where a value can be found)
> versus implicit location descriptions (e.g. DW_OP_value) versus
> composite location descriptions (e.g. DW_OP_piece).
>
> It might be that we don't care, because all we care about is whether or
> not we can get a value, but it would validate the interface.
>
> Having some examples/testcases would also show how/where to get the
> DWARF expressions to use with this new function.
Sounds good, I'll put some examples/test cases together. FWIW, I'm using
it in drgn to get register values like so:
LIBDRGN_PUBLIC struct drgn_error *
drgn_stack_frame_register(struct drgn_stack_frame frame,
enum drgn_register_number regno, uint64_t *ret)
{
const Dwarf_Op op = { .atom = DW_OP_regx, .number = regno, };
Dwarf_Addr value;
if (!dwfl_frame_eval_expr(frame.trace->frames[frame.i], &op, 1, &value))
return drgn_error_libdwfl();
*ret = value;
return NULL;
}
Later, I plan to use this for location expressions for local variables
that I get out of DWARF.
Thanks,
Omar
