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 m...@milianw.de http://milianw.de
signature.asc
Description: This is a digitally signed message part.
