From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 104469 invoked by alias); 30 Mar 2017 11:14:52 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 102872 invoked by uid 89); 30 Mar 2017 11:14:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.2 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=H*F:U*mail, Thursday, thursday, our X-Spam-Status: No, score=-1.6 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: dd17628.kasserver.com From: Milian Wolff To: elfutils-devel@sourceware.org Cc: Mark Wielaard Subject: Re: dwfl_attach_state alternative taking Ebl? Date: Thu, 30 Mar 2017 11:14:00 -0000 Message-ID: <1563796.tLH0IFhUAp@milian-kdab2> In-Reply-To: <1490871453.6461.169.camel@klomp.org> References: <2572422.AxEj1gHkJW@milian-kdab2> <1662463.uA56NKcFP1@agathebauer> <1490871453.6461.169.camel@klomp.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" X-SW-Source: 2017-q1/txt/msg00152.txt.bz2 On Thursday, March 30, 2017 12:57:33 PM CEST Mark Wielaard wrote: > On Wed, 2017-03-29 at 23:57 +0200, Milian Wolff wrote: > > On Mittwoch, 29. M=E4rz 2017 21:48:08 CEST Mark Wielaard wrote: > > > Would it help your use case if there was a dwfl_init_state (Dwfl *dwf= l, > > > int e_machine, unsigned char ei_class, unsigned char ei_data, ...)? > >=20 > > What magic values do I pass to e_machine, ei_class, ei_data? >=20 > That would be one of the EM e_machine architecture constants, ELFCLASS32 > or ELFCLASS64 for ei_class and ELFDATA2LSB or ELFDATA2MSB for ei_data. > (e_machine could arguably be a GElf_Half). >=20 > > I guess the ebl API that takes the Elf architecture or archicture > > name would be better. >=20 > I think we should extend the ebl_openbackend calls with a variant that > takes all three machine/class/data constants. If you look at the > machines table in libebl/eblopenbackend.c you see that given just the EM > architecture constant or (emulation) name without an Elf handle given we > cannot distinguish between e.g. ppc64 (EM_PPC64/ELFCLASS64/ELFDATA2MSB) > and ppc64le (EM_PPC64/ELFCLASS64/ELFDATA2LSB). You may obviously counter > that just means that table isn't complete. But then we have to document > (and maybe export?) the emulation names that people can rely on. Which > is why I was suggesting we rely on the machine/class/data triple to > uniquely identify the architecture. Maybe that is inconvenient though? Ah ok, such a triple would be OK as well, I guess. But see below. > > > And what exactly is your use case? Maybe we can come up with a better > > > interface. > >=20 > > 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 fig= ure > > 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... >=20 > 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 o= n=20 the command line. In both cases it is a string like "x86_64", "arm" or=20 "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 dw= fl/ elf counterpart would simplify our code, or at least would make it easier t= o=20 understand, as we wouldn't have to wait for an Elf file we can open before= =20 calling dwfl_attach_state. Bye --=20 Milian Wolff mail@milianw.de http://milianw.de