On 07/10/2024 10:04 am, Jan Beulich wrote: > On 07.10.2024 10:15, Frediano Ziglio wrote: >> On Mon, Oct 7, 2024 at 9:07 AM Frediano Ziglio >> <[email protected]> wrote: >>> On Mon, Oct 7, 2024 at 8:03 AM Jan Beulich <[email protected]> wrote: >>>> On 05.10.2024 15:21, Andrew Cooper wrote: >>>>> On 05/10/2024 9:02 am, Frediano Ziglio wrote: >>>>>> --- a/xen/arch/x86/boot/Makefile >>>>>> +++ b/xen/arch/x86/boot/Makefile >>>>>> @@ -1,6 +1,6 @@ >>>>>> -obj-bin-y += head.o cbundle.o >>>>>> +obj-bin-y += head.o cbundle.o reloc-trampoline.x64.o >>>>> Ah. I think the $(obj)/%.x64.o rule you had in the previous patch wants >>>>> introducing here. >>>>> >>>>> That said, x64 is the one name for 64bit that we reliably don't use. >>>>> Also... >>>>> >>>>>> -head-bin-objs := cmdline.o reloc.o >>>>>> +head-bin-objs := cmdline.o reloc.o reloc-trampoline.o >>>>> ... head-bin-objs isn't really correct now seeing as they're not >>>>> binaries in head.S. Also ... >>>>> >>>>>> nocov-y += $(head-bin-objs) >>>>>> noubsan-y += $(head-bin-objs) >>>>> The no$(foo)'s needs extending to the 64bit objects too. They're also >>>>> used early enough to explode. >>>>> >>>>> In Xen, 64bit objects are the norm, and it's 32bit ones which are the >>>>> exception, so how about we special case *.i386.o instead. Then >>>>> >>>>> obj32 := cmdline.i386.o >>>>> obj32 += reloc.i386.o >>>>> obj32 += reloc-trampoline.i386.o >>>> I'd like to advocate for ix86 or i686. i386 gives a wrong impression imo. >>> Why not simply x86 ? We already use it. >>> >> Looking at current files, we also use (to distinguish more clearly 32 >> and 64 bit) x86_32. > Either would be fine with me; as to x86 I took it that Andrew wanted to > express the 32-bit-ness, which x86 alone doesn't unambiguously do.
On further thought, why not just foo.32.o ? That should be clear enough. ~Andrew
