From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26424 invoked by alias); 29 Mar 2017 19:48:33 -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 22148 invoked by uid 89); 29 Mar 2017 19:48:25 -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.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY autolearn=no version=3.3.2 spammy=H*M:155 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: <1490816888.6461.155.camel@klomp.org> Subject: Re: dwfl_attach_state alternative taking Ebl? From: Mark Wielaard To: Milian Wolff Cc: elfutils-devel@sourceware.org Date: Wed, 29 Mar 2017 19:48:00 -0000 In-Reply-To: <2572422.AxEj1gHkJW@milian-kdab2> References: <2572422.AxEj1gHkJW@milian-kdab2> 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/msg00143.txt.bz2 Hi Milian, 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=20 > dwfl_attach_state taking an Ebl pointer instead of the Elf* to guess the= =20 > architecture from? 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. > This would simplify the code for cases where we know the architecture, bu= t=20 > don't necessarily have a corresponding Elf* at hand (yet). If there'd be = a=20 > version that takes the Ebl pointer directly, one could use e.g.=20 > ebl_openbackend_emulation or _machine to find the backend handle for the = known=20 > target architecture directly. >=20 > If this would be acceptable, I will write a patch up for this. I would ne= ed=20 > suggestions for a fitting name though, in C++ I'd simply use an overload = but=20 > here with plain C... ;-) 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, ...)? And what exactly is your use case? Maybe we can come up with a better interface. Thanks, Mark