dwfl_attach_state alternative taking Ebl?

[Milian Wolff]

On Mittwoch, 29. März 2017 21:48:08 CEST Mark Wielaard wrote:
> 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.

Ah right, I only looked at the implementation of dwfl_attach_state and related 
sources without reading the comment saying that Ebl is internal. No-go then.

> > 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, ...)?

What magic values do I pass to e_machine, ei_class, ei_data? I guess the ebl 
API that takes the Elf architecture or archicture name would be better.

> And what exactly is your use case? Maybe we can come up with a better
> interface.

The use-case is parsing profiler data, e.g. in perfparser by Ulf / TQC. We 
don't mess with Elf* anywhere, but need it to let dwfl_attach_state figure out 
the target architecture. We do know the architecture already so this is a lot 
of jumping through hoops, to find a fitting Elf* that can be used for dwfl 
then...

-- 
Milian Wolff
mail@milianw.de
http://milianw.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://sourceware.org/pipermail/elfutils-devel/attachments/20170329/e356e6cf/attachment.sig>