Telling just the compiler to produce little-endian objects isn't enough.

Signed-off-by: Jan Beulich <jbeulich@suse.com>

--- a/xen/arch/ppc/arch.mk
+++ b/xen/arch/ppc/arch.mk
@@ -7,6 +7,8 @@ ppc-march-$(CONFIG_POWER_ISA_3_00) := po
 CFLAGS += -m64 -mlittle-endian -mcpu=$(ppc-march-y)
 CFLAGS += -mstrict-align -mcmodel=large -mabi=elfv2 -mno-altivec -mno-vsx
 
+LDFLAGS += -m elf64lppc
+
 # TODO: Drop override when more of the build is working
 override ALL_OBJS-y = arch/$(SRCARCH)/built_in.o
 override ALL_LIBS-y =

On 7/5/23 9:44 AM, Jan Beulich wrote:
> Telling just the compiler to produce little-endian objects isn't enough.
> 
> Signed-off-by: Jan Beulich <jbeulich@suse.com>
> 
> --- a/xen/arch/ppc/arch.mk
> +++ b/xen/arch/ppc/arch.mk
> @@ -7,6 +7,8 @@ ppc-march-$(CONFIG_POWER_ISA_3_00) := po
>  CFLAGS += -m64 -mlittle-endian -mcpu=$(ppc-march-y)
>  CFLAGS += -mstrict-align -mcmodel=large -mabi=elfv2 -mno-altivec -mno-vsx
>  
> +LDFLAGS += -m elf64lppc

Looking around, it seems GNU ld also has a -EL flag:

  -EL Link little-endian objects.  This affects the default output format.

Linux's build system passes both -EL and -m elf64lppc, though I'm
wondering if -EL alone would be enough.

In any case, this doesn't break the build with my ppc64le toolchain, so
if this fixes issues you're seeing with BE toolchains then it's fine
with me.

>  # TODO: Drop override when more of the build is working
>  override ALL_OBJS-y = arch/$(SRCARCH)/built_in.o
>  override ALL_LIBS-y =

Acked-by: Shawn Anastasio <sanastasio@raptorengineering.com>

On 05.07.2023 17:10, Shawn Anastasio wrote:
> On 7/5/23 9:44 AM, Jan Beulich wrote:
>> Telling just the compiler to produce little-endian objects isn't enough.
>>
>> Signed-off-by: Jan Beulich <jbeulich@suse.com>
>>
>> --- a/xen/arch/ppc/arch.mk
>> +++ b/xen/arch/ppc/arch.mk
>> @@ -7,6 +7,8 @@ ppc-march-$(CONFIG_POWER_ISA_3_00) := po
>>  CFLAGS += -m64 -mlittle-endian -mcpu=$(ppc-march-y)
>>  CFLAGS += -mstrict-align -mcmodel=large -mabi=elfv2 -mno-altivec -mno-vsx
>>  
>> +LDFLAGS += -m elf64lppc
> 
> Looking around, it seems GNU ld also has a -EL flag:
> 
>   -EL Link little-endian objects.  This affects the default output format.
> 
> Linux's build system passes both -EL and -m elf64lppc, though I'm
> wondering if -EL alone would be enough.

What I did is check what gcc passes to ld when itself passed -mlittle
or -mlittle-endian.

> In any case, this doesn't break the build with my ppc64le toolchain, so
> if this fixes issues you're seeing with BE toolchains then it's fine
> with me.
> 
>>  # TODO: Drop override when more of the build is working
>>  override ALL_OBJS-y = arch/$(SRCARCH)/built_in.o
>>  override ALL_LIBS-y =
> 
> Acked-by: Shawn Anastasio <sanastasio@raptorengineering.com>

Thanks.

Jan

On 7/5/23 11:09 AM, Jan Beulich wrote:
> On 05.07.2023 17:10, Shawn Anastasio wrote:
>> Acked-by: Shawn Anastasio <sanastasio@raptorengineering.com>
> 
> Thanks.

Just to clarify, as the maintainer of PPC64, would it be my
responsibility to commit this now directly to xen/staging? Or should I
commit it to my own tree and have someone pull it?

I'm not super familiar with the project's maintainer workflow yet so any
hints would be appreciated.

> Jan

Thanks,
Shawn

On 05/07/2023 5:22 pm, Shawn Anastasio wrote:
> On 7/5/23 11:09 AM, Jan Beulich wrote:
>> On 05.07.2023 17:10, Shawn Anastasio wrote:
>>> Acked-by: Shawn Anastasio <sanastasio@raptorengineering.com>
>> Thanks.
> Just to clarify, as the maintainer of PPC64, would it be my
> responsibility to commit this now directly to xen/staging? Or should I
> commit it to my own tree and have someone pull it?
>
> I'm not super familiar with the project's maintainer workflow yet so any
> hints would be appreciated.

Ah, so this is somewhere where we're quite different to Linux.

There is one single tree, and there are a small group of people with
commit access.  We're "THE REST" in the maintainers file.  Jan can
commit, as can I, and several others.

The role of committers is (technically at least) to take any patch from
the mailing list which is suitably acked, and commit it.

So, in principle you have nothing further to do here.  As this is one of
Jan's patches, I'm sure he'll include in in the next set of patches he
commits.

It can happen that patches fall between the cracks, so it is generally
helpful for maintainers to double check and ping on IRC/email/etc if
there are patches that appear to be outstanding.

~Andrew

On 7/5/23 11:53 AM, Andrew Cooper wrote:
> On 05/07/2023 5:22 pm, Shawn Anastasio wrote:
>> On 7/5/23 11:09 AM, Jan Beulich wrote:
>>> On 05.07.2023 17:10, Shawn Anastasio wrote:
>>>> Acked-by: Shawn Anastasio <sanastasio@raptorengineering.com>
>>> Thanks.
>> Just to clarify, as the maintainer of PPC64, would it be my
>> responsibility to commit this now directly to xen/staging? Or should I
>> commit it to my own tree and have someone pull it?
>>
>> I'm not super familiar with the project's maintainer workflow yet so any
>> hints would be appreciated.
> 
> Ah, so this is somewhere where we're quite different to Linux.
> 
> There is one single tree, and there are a small group of people with
> commit access.  We're "THE REST" in the maintainers file.  Jan can
> commit, as can I, and several others.
> 
> The role of committers is (technically at least) to take any patch from
> the mailing list which is suitably acked, and commit it.
> 
> So, in principle you have nothing further to do here.  As this is one of
> Jan's patches, I'm sure he'll include in in the next set of patches he
> commits.
> 
> It can happen that patches fall between the cracks, so it is generally
> helpful for maintainers to double check and ping on IRC/email/etc if
> there are patches that appear to be outstanding.
> 
> ~Andrew

Thanks for the explanation, that makes sense.

Shawn