This is the mail archive of the elfutils-devel@sourceware.org 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 01, 2019 at 05:08:15PM +0000, Sasha Da Rocha Pinheiro wrote:
> yes, I did use dwarf_frame_register(), I believe I mentioned that :).

Sorry, I missed that.

> In the case I brought up you're saying it was an elfutils' libdw
> decision to provide negative number as DW_OP_plus_uconst (unsigned
> constant)? So there would be no harm to cast it to a signed int??

Yes, since I don't believe there is a better representation.
There is no DW_OP_plus_sconst for example.

> Do you know if the rules to find the registers will always have only
> another one register associated to it?  Because libdwarf function
> dwarf_get_fde_info_for_reg3() returns a register_num, which is
> described as: "Argument register_num should point to a location
> which will hold the register number associated with the register
> rule."

I am not familiar with libdwarf, so don't know how to answer this question

> elfutils only gives us a location description in an array of
> Dwarf_Op. Does it provide methods to "execute" it so we can get the
> result of the expressions? Or it delegates it to the consumer?

It doesn't have a generic location description "executor". It really
should have. But to make it generic it needs a lot of context.

libdwfl does contain a partial operator interpreter for unwinding. See
expr_eval in libdwfl/frame_unwind.c. To turn that into something more
generic we would need some way to provide it with things like memory
accessors and register values. libdwfl provides some of that through
dwfl_attach_state.

Cheers,

Mark


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