On Sat, 12 Oct 2013 22:52:23 +0200, Mark Wielaard wrote:
> So the user cannot rely on anything in libebl.h (except maybe
> ebl_openbackend and ebl_closebackend).
Here the user calls ebl_openbackend + ebl_closebackend, if user wants to
reimplement core files support s/he also calls ebl_core_note.
We don't support the ebl_* interface, so they cannot use/rely on
those since they are internal only interfaces that can and will
randomly change. If they want to, we have to design and provide
a real libdw/dwfl interface for those.
> Instead of an Ebl *, could dwfl_attach_state take an Elf *?
This really seems as an incorrect API. The parameter expresses arch (to
specify register set and unwinding specifics). What if one unwinds internal
memory image, then one would have to create artificial Elf just so that one
can specify the arch with it.
I thought it somewhat natural since it would be the "main ELF" file (e.g.
core file or executable) that the Dwfl was intented to represent. But I
would also be fine with a simple e_machine int to indicate the arch.