dwfl_attach_state alternative taking Ebl?
Wed Mar 29 19:48:00 GMT 2017
On Wed, 2017-03-29 at 16:50 +0200, Milian Wolff wrote:
> would you be willing to accept a patch that adds an alternative to
> dwfl_attach_state taking an Ebl pointer instead of the Elf* to guess the
> architecture from?
I rather not expose an Ebl handle to the public interface.
It is really an internal interface that we can change anytime.
There is also no way a user can create or get at an Ebl handle using the
> This would simplify the code for cases where we know the architecture, but
> don't necessarily have a corresponding Elf* at hand (yet). If there'd be a
> version that takes the Ebl pointer directly, one could use e.g.
> ebl_openbackend_emulation or _machine to find the backend handle for the known
> target architecture directly.
> If this would be acceptable, I will write a patch up for this. I would need
> suggestions for a fitting name though, in C++ I'd simply use an overload but
> here with plain C... ;-)
Would it help your use case if there was a dwfl_init_state (Dwfl *dwfl,
int e_machine, unsigned char ei_class, unsigned char ei_data, ...)?
And what exactly is your use case? Maybe we can come up with a better
More information about the Elfutils-devel