Re: dwfl_attach_state alternative taking Ebl?

[Mark Wielaard <mark at klomp dot org>]

Hi Milian,

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
public interfaces.

> 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
interface.

Thanks,

Mark