From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 41016 invoked by alias); 29 Mar 2017 21:57:31 -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 41004 invoked by uid 89); 29 Mar 2017 21:57:30 -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=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=H*F:U*mail, mrz, mittwoch, Hx-languages-length:2024 X-Spam-Status: No, score=-1.6 required=5.0 tests=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: Mark Wielaard Cc: elfutils-devel@sourceware.org Subject: Re: dwfl_attach_state alternative taking Ebl? Date: Wed, 29 Mar 2017 21:57:00 -0000 Message-ID: <1662463.uA56NKcFP1@agathebauer> In-Reply-To: <1490816888.6461.155.camel@klomp.org> References: <2572422.AxEj1gHkJW@milian-kdab2> <1490816888.6461.155.camel@klomp.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart5327817.CPyxISqQPs"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-SW-Source: 2017-q1/txt/msg00145.txt.bz2 --nextPart5327817.CPyxISqQPs Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Content-length: 2029 On Mittwoch, 29. M=E4rz 2017 21:48:08 CEST Mark Wielaard wrote: > Hi Milian, >=20 > On Wed, 2017-03-29 at 16:50 +0200, Milian Wolff wrote: > > would you be willing to accept a patch that adds an alternative to > > dwfl_attach_state taking an Ebl pointer instead of the Elf* to guess the > > architecture from? >=20 > I rather not expose an Ebl handle to the public interface. > It is really an internal interface that we can change anytime. > There is also no way a user can create or get at an Ebl handle using the > public interfaces. Ah right, I only looked at the implementation of dwfl_attach_state and rela= ted=20 sources without reading the comment saying that Ebl is internal. No-go then. > > This would simplify the code for cases where we know the architecture, = but > > don't necessarily have a corresponding Elf* at hand (yet). If there'd b= e a > > version that takes the Ebl pointer directly, one could use e.g. > > ebl_openbackend_emulation or _machine to find the backend handle for the > > known target architecture directly. > >=20 > > If this would be acceptable, I will write a patch up for this. I would > > need > > suggestions for a fitting name though, in C++ I'd simply use an overload > > but here with plain C... ;-) >=20 > 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, ...)? What magic values do I pass to e_machine, ei_class, ei_data? I guess the eb= l=20 API that takes the Elf architecture or archicture name would be better. > And what exactly is your use case? Maybe we can come up with a better > interface. The use-case is parsing profiler data, e.g. in perfparser by Ulf / TQC. We= =20 don't mess with Elf* anywhere, but need it to let dwfl_attach_state figure = out=20 the target architecture. We do know the architecture already so this is a l= ot=20 of jumping through hoops, to find a fitting Elf* that can be used for dwfl= =20 then... --=20 Milian Wolff mail@milianw.de http://milianw.de= --nextPart5327817.CPyxISqQPs Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit Content-length: 195 -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQQ9hWiGkJfGXJj40nYMDrISzR0TkwUCWNwtxgAKCRAMDrISzR0T k3lbAKCym2hh5r1I5k/7r3NfTcHsJDr0PgCeJCt3ZlX9ESu6beTKc84+37oOQKY= =vTQ4 -----END PGP SIGNATURE----- --nextPart5327817.CPyxISqQPs--