| Message ID | f56a208f-97d1-b7ec-afad-3b7bc180cf87@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | ppc: make also linking work with big-endian tool chain | expand |
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
--- 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 =
Telling just the compiler to produce little-endian objects isn't enough. Signed-off-by: Jan Beulich <jbeulich@suse.com>