From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 64632 invoked by alias); 30 Mar 2017 10:57:36 -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 64612 invoked by uid 89); 30 Mar 2017 10:57:35 -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: =?ISO-8859-1?Q?No, score=-1.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=m=c3=a4rz, Hx-languages-length:1940?= X-Spam-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY 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: gnu.wildebeest.org Message-ID: <1490871453.6461.169.camel@klomp.org> Subject: Re: dwfl_attach_state alternative taking Ebl? From: Mark Wielaard To: Milian Wolff Cc: elfutils-devel@sourceware.org Date: Thu, 30 Mar 2017 10:57:00 -0000 In-Reply-To: <1662463.uA56NKcFP1@agathebauer> References: <2572422.AxEj1gHkJW@milian-kdab2> <1490816888.6461.155.camel@klomp.org> <1662463.uA56NKcFP1@agathebauer> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Mailer: Evolution 3.12.11 (3.12.11-22.el7) Mime-Version: 1.0 X-SW-Source: 2017-q1/txt/msg00151.txt.bz2 On Wed, 2017-03-29 at 23:57 +0200, Milian Wolff wrote: > On Mittwoch, 29. M=C3=A4rz 2017 21:48:08 CEST Mark Wielaard wrote: > > 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, ...)? >=20 > What magic values do I pass to e_machine, ei_class, ei_data? 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). > I guess the ebl API that takes the Elf architecture or archicture > name would be better. 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? > > 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. W= e=20 > don't mess with Elf* anywhere, but need it to let dwfl_attach_state figur= e out=20 > the target architecture. We do know the architecture already so this is a= lot=20 > of jumping through hoops, to find a fitting Elf* that can be used for dwf= l=20 > then... 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? Cheers, Mark