This is the mail archive of the
mailing list for the elfutils project.
Re: [patch v5] unwinder: The unwinder (x86* only)
- From: Mark Wielaard <mjw at redhat dot com>
- To: elfutils-devel at lists dot fedorahosted dot org
- Date: Sun, 13 Oct 2013 05:18:54 -0400
- Subject: Re: [patch v5] unwinder: The unwinder (x86* only)
> 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.