Re: [PATCH 2/3] x86/boot: Reuse code to relocate trampoline

[Jan Beulich <jbeulich@xxxxxxxx>]

On 07.10.2024 12:00, Frediano Ziglio wrote:
> On Mon, Oct 7, 2024 at 10:47 AM Andrew Cooper <andrew.cooper3@xxxxxxxxxx> 
> wrote:
>>
>> 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
>>>> <frediano.ziglio@xxxxxxxxx> wrote:
>>>>> On Mon, Oct 7, 2024 at 8:03 AM Jan Beulich <jbeulich@xxxxxxxx> 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.
> 
> At this point, it starts to be more of a personal preference.
> I slightly prefer x86_32 looking at file names and Makefile's macros.
> Pick one.

I like Andrew's most recent suggestion, fwiw.

Jan