This is the mail archive of the
elfutils-devel@sourceware.org
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, 05 Apr 2017 14:46:34 +0200
- Subject: Re: dwfl_attach_state alternative taking Ebl?
- Authentication-results: sourceware.org; auth=none
- References: <2572422.AxEj1gHkJW@milian-kdab2> <1662463.uA56NKcFP1@agathebauer> <1490871453.6461.169.camel@klomp.org> <1563796.tLH0IFhUAp@milian-kdab2>
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?
Thanks,
Mark