Re: dwfl_attach_state alternative taking Ebl?

[Mark Wielaard <mark at klomp dot org>]

On Wed, 2017-04-05 at 15:04 +0200, Milian Wolff wrote:
> On Wednesday, April 5, 2017 2:46:34 PM CEST Mark Wielaard wrote:
> > On Thu, 2017-03-30 at 13:14 +0200, Milian Wolff wrote:
> > > > OK. How do you know the Elf architecture in that case? How and by what
> > > > is it given? Is that an EM constant or some architecture string?
> > > 
> > > In our case we either get it from perf, or the user specifies it directly
> > > on the command line. In both cases it is a string like "x86_64", "arm" or
> > > "aarch64". We map that to a list of architectures we know about, see
> > > e.g.:
> > > 
> > > http://code.qt.io/cgit/qt-creator/perfparser.git/tree/app/
> > > perfregisterinfo.h#n29
> > > 
> > > So, any API that would allow us to map these architectures directly to a
> > > dwfl/ elf counterpart would simplify our code, or at least would make it
> > > easier to understand, as we wouldn't have to wait for an Elf file we can
> > > open before calling dwfl_attach_state.
> > 
> > So you map from simple architecture name like "x86" or "powerpc". But
> > what mechanism do you have to whether that is 32 or 64 bit, and big or
> > little endian?
> 
> As Ulf said, we can add the required mappings. So from my side, I guess your 
> approach with the three machine/class/data constants would be a good 
> improvement already.

OK, so we could add a dwfl_attach_arch_state which is almost like
dwfl_attach_state except instead of an ELF it would take machine, class,
data.

bool dwfl_attach_arch_state (Dwfl *dwfl, GElf_Half e_machine,
                             unsigned char ei_class,
                             unsigned char ei_data, pid_t pid,
                             const Dwfl_Thread_Callbacks *thread_callbacks,
                             void *dwfl_arg);

But before we do I like to understand your use case a little better, to
make sure it is really necessary (once we add a public interface we are
stuck with it forever).

First note that providing an Elf handle to dwfl_attach_arch_state isn't
necessary if the Dwfl already has Dwfl_Modules, then it can guess the
architecture from the Elf associated with the Dwfl_Modules. From the
documentation:

/* [...] Architecture of DWFL  
   modules is specified by ELF, ELF must remain valid during DWFL lifetime.     
   Use NULL ELF to detect architecture from DWFL, the function will then detect
   it from arbitrary Dwfl_Module of DWFL.  [...]  */

So would that be an alternative for you? How do you create the Dwfl? Do
you add modules to it (how?) and when do you need to call
dwfl_attach_state?

Thanks,

Mark