This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


Re: [XenPPC] Re: [Xen-devel] Re: [patch] make ELF functions static

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.Campbell@xxxxxxxxxxxxx> 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

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 :)


Xen-devel mailing list