Hi Michael, On 19/06/15 02:08, Michael Ellerman wrote: > On Thu, 2015-06-18 at 15:52 +0100, Andre Przywara wrote: >> Hi, >> >> On 06/17/2015 10:43 AM, Andre Przywara wrote: >>> For converting the guest/init binary into an object file, we call >>> the linker binary, setting the endianness to big endian explicitly >>> when compiling kvmtool for powerpc. >>> This breaks if the compiler is actually targetting little endian >>> (which is true for the Debian port, for instance). >>> Remove the explicit big endianness switch from the linker call to >>> allow linking on little endian PowerPC builds again. >>> >>> Signed-off-by: Andre Przywara <andre.przyw...@arm.com> >>> --- >>> Hi, >>> >>> this fixed the powerpc64le build for me, while still compiling fine >>> for big endian. Admittedly this whole init->guest_init.o conversion >>> has its issues (with MIPS, for instance), which deserve proper fixing, >>> but lets just fix that build for now. >> >> Will was concerned about breaking toolchains where the linker does not >> default to 64-bit. Is that an issue we care about? > > Yeah, that would be Debian & Ubuntu BE at least, and maybe Fedora too? I'm not > sure how you compiled it big endian?
I have my own cross-compiler built from scratch. This is powerpc64-linux-gnu, which is big endian. I don't have any distribution behind it, it's just a cross-compiler with glibc. >> AFAICT LDFLAGS is only used in this dodgy binary-to-object-file >> conversion of guest/init. For this we rely on the resulting .o file to >> have the same ELF target as the other object files to be finally linked >> into the lkvm binary. As we don't compile guest/init with CFLAGS, there >> is a possible mismatch. >> >> I am looking into a proper fix for this now (compiling guest/init with >> CFLAGS, calling $CC with linker options instead of $LD and allowing CC >> and LD override). Still struggling with MIPS, though :-( > > Yeah that's obviously a better solution medium term. > > Can you do something like this? Sorry untested: > > diff --git a/Makefile b/Makefile > index 6110b8e..8663d67 100644 > --- a/Makefile > +++ b/Makefile > @@ -149,7 +149,11 @@ ifeq ($(ARCH), powerpc) > OBJS += powerpc/xics.o > ARCH_INCLUDE := powerpc/include > CFLAGS += -m64 > - LDFLAGS += -m elf64ppc > + ifeq ($(call try-build,$(SOURCE_HELLO),$(CFLAGS),-m elf64ppc),y) > + LDFLAGS += -m elf64ppc > + else > + LDFLAGS += -m elf64leppc > + endif > > ARCH_WANT_LIBFDT := y > endif Nah, actually I want to get rid of those LDFLAGS at all. For some reasons using ld to convert a random binary file into a C object is causing trouble on MIPS, because ld uses a slightly different ELF target than CC there. I think this conversion should be more a job for objcopy than for ld, but that does not fix the problem in a generic way (though I was able to hack it with some magic objcopy options). What works though is using xxd to convert the binary guest/init into a C array: $ xxd -i guest/init | $(CC) -x c -c - -o guest/guest_init.o This has the nice property of using the same compiler that generates the other object files and thus automatically matches them (which is a problem under MIPS atm, as ld seems to default to some different ELF type). The only issue is that xxd is part of the vim package, which would annoy Emacs users. Not sure we are in a position to mandate vim for compiling kvmtool ;-) Cheers, Andre. -- To unsubscribe from this list: send the line "unsubscribe kvm-ppc" in
