8 messages in com.xensource.lists.xen-develRe: [XenPPC] Re: [Xen-devel] Re: [pat...
FromSent OnAttachments
Hollis Blanchard29 Aug 2006 14:15 
Ian Campbell30 Aug 2006 00:03 
Jan Beulich30 Aug 2006 01:38 
Gerd Hoffmann30 Aug 2006 01:44 
Ian Campbell30 Aug 2006 02:06 
Jimi Xenidis30 Aug 2006 04:00 
Gerd Hoffmann30 Aug 2006 04:12 
Jan Beulich30 Aug 2006 04:44 
Subject:Re: [XenPPC] Re: [Xen-devel] Re: [patch] make ELF functions static
From:Jimi Xenidis (jim@watson.ibm.com)
Date:08/30/2006 04:00:09 AM
List:com.xensource.lists.xen-devel

On Aug 30, 2006, at 5:06 AM, Ian Campbell wrote:

On Wed, 2006-08-30 at 09:38 +0100, Jan Beulich wrote:

Ian Campbell <Ian.@XenSource.com> 30.08.06 09:03 >>>

On Tue, 2006-08-29 at 16:15 -0500, Hollis Blanchard wrote:

Hi Ian, these functions should be static. It would only be a style issue except PowerPC actually #includes elf.c twice, to support both 32- and 64-bit ELF binaries. Please apply.

Unfortunately they are referenced from outside this file (xen/arch/x86/domain_build.c).

I'm not sure what a good short term fix for you would be. Perhaps some preprocessor/CFLAGS magic to name them xen_elfnote32_foo and xen_elfnote64_foo when compiling powerpc?

Hopefully long term the 32-on-64 work that is going on will lead to ELF code which doesn't need to be multiply compiled.

Why? It's simpler to compile it twice. I already posted draft patches to do this, simply introducing an elf32.c that #define-s the relevant symbols to alternative names and that only gets compiled when 64-bit arches need it for supporting 32-bit binaries.

Fair enough. I should probably have said something like "solves the problem cleanly for everyone" rather than speculating about how we would go about it ;-)

Ok now that we have established the "compile twice" strategy, then why don't we stick them in a new file called elfnote.c and keep them global?

Can we do the same for tools/libxc/xc_load_elf.c as well since its on my todo list to get that building twice too :)

-JX