Re: [PATCH 2/3] powerpc: use default endianness for converting guest/init

[Andre Przywara <andre.przywara@arm.com>]

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.przywara@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