From mboxrd@z Thu Jan 1 00:00:00 1970 From: Konrad Rzeszutek Wilk Subject: Re: [PATCH v1 1/3] libelf: Preserve log callback after elf_init Date: Mon, 5 Oct 2015 10:48:15 -0400 Message-ID: <20151005144815.GA2642@l.oracle.com> References: <1443897590-5663-1-git-send-email-konrad.wilk@oracle.com> <1443897590-5663-2-git-send-email-konrad.wilk@oracle.com> <56126EDB02000078000A80D0@prv-mh.provo.novell.com> <20151005142331.GE2256@l.oracle.com> <5612A7D502000078000A831F@prv-mh.provo.novell.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Return-path: Received: from mail6.bemta5.messagelabs.com ([195.245.231.135]) by lists.xen.org with esmtp (Exim 4.72) (envelope-from ) id 1Zj73y-000453-Vv for xen-devel@lists.xenproject.org; Mon, 05 Oct 2015 14:48:27 +0000 Content-Disposition: inline In-Reply-To: <5612A7D502000078000A831F@prv-mh.provo.novell.com> List-Unsubscribe: , List-Post: List-Help: List-Subscribe: , Sender: xen-devel-bounces@lists.xen.org Errors-To: xen-devel-bounces@lists.xen.org To: Jan Beulich Cc: xen-devel@lists.xenproject.org, keir@xen.org, ian.jackson@eu.citrix.com, ian.campbell@citrix.com, tim@xen.org List-Id: xen-devel@lists.xenproject.org On Mon, Oct 05, 2015 at 08:39:49AM -0600, Jan Beulich wrote: > >>> On 05.10.15 at 16:23, wrote: > > On Mon, Oct 05, 2015 at 04:36:43AM -0600, Jan Beulich wrote: > >> >>> On 03.10.15 at 20:39, wrote: > >> > The elf_init function uses the log callback to report > >> > errors. But it also memsets the whole structure so the > >> > log callback (if set) is wiped out! > >> > >> Only if you set it before calling elf_init(), which - looking at all current > >> in-tree users isn't intended. > > > > Right? But if you are developing against how else would > > you find out that you have issues? > > > > As in, if elf_init can't process the virtual address it tries > > to call efi_msg to tell me what I did wrong, but that will always > > end up silently (at least on user-space code). > > Ah, so you really mean _for_ instead of _after_ in the subject > (and then perhaps also not "preserve")? In that case, however, Argh! Yes! > I wonder whether the respective information shouldn't be passed > to elf_init() instead of being set up front (e.g. by introducing a > struct elf_log container). Let me prep a patch to that effect this week. > > Jan >