This is the mail archive of the
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> <firstname.lastname@example.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.:
> 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