This is the mail archive of the
mailing list for the elfutils project.
Re: dwfl_attach_state alternative taking Ebl?
- From: Mark Wielaard <mark at klomp dot org>
- To: Milian Wolff <mail at milianw dot de>
- Cc: elfutils-devel at sourceware dot org
- Date: Wed, 29 Mar 2017 21:48:08 +0200
- Subject: Re: dwfl_attach_state alternative taking Ebl?
- Authentication-results: sourceware.org; auth=none
- References: <2572422.AxEj1gHkJW@milian-kdab2>
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