> 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. Cheers, Mark
