All of lore.kernel.org
 help / color / mirror / Atom feed
From: Michal Orzel <michal.orzel@arm.com>
To: Jan Beulich <jbeulich@suse.com>, Julien Grall <julien@xen.org>
Cc: "Stefano Stabellini" <sstabellini@kernel.org>,
	"Bertrand Marquis" <bertrand.marquis@arm.com>,
	"Volodymyr Babchuk" <Volodymyr_Babchuk@epam.com>,
	"Andrew Cooper" <andrew.cooper3@citrix.com>,
	"George Dunlap" <george.dunlap@citrix.com>,
	"Wei Liu" <wl@xen.org>, "Roger Pau Monné" <roger.pau@citrix.com>,
	xen-devel@lists.xenproject.org
Subject: Re: [PATCH v2 2/2] xen: Populate xen.lds.h and make use of its macros
Date: Wed, 30 Mar 2022 13:04:15 +0200	[thread overview]
Message-ID: <ffa0e581-6a32-5c3c-7e63-acd5086c6822@arm.com> (raw)
In-Reply-To: <1013a14b-a45b-f37f-b2e0-e63b186a2956@suse.com>

Hello,

On 30.03.2022 12:42, Jan Beulich wrote:
> On 30.03.2022 12:32, Julien Grall wrote:
>> On 29/03/2022 12:42, Jan Beulich wrote:
>>> On 29.03.2022 12:54, Julien Grall wrote:
>>>> On 29/03/2022 11:12, Michal Orzel wrote:
>>>>> On 29.03.2022 11:54, Julien Grall wrote:
>>>>>> On 22/03/2022 08:02, Michal Orzel wrote:
>>>>>>> --- a/xen/include/xen/xen.lds.h
>>>>>>> +++ b/xen/include/xen/xen.lds.h
>>>>>>> @@ -5,4 +5,104 @@
>>>>>>>      * Common macros to be used in architecture specific linker scripts.
>>>>>>>      */
>>>>>>>     +/* Macros to declare debug sections. */
>>>>>>> +#ifdef EFI
>>>>>>
>>>>>> AFAIK, we don't define EFI on Arm (just CONFIG_EFI). Yet we do support EFI on arm64.
>>>>>>
>>>>>> As this #ifdef is now in generic code, can you explain how this is meant to be used?
>>>>>>
>>>>> As we do not define EFI on arm, all the stuff protected by #ifdef EFI is x86 specific.
>>>>
>>>> I find the name "EFI" too generic to figure out that this code can only
>>>> be used by x86.
>>>>
>>>> But, from my understanding, this header is meant to contain generic
>>>> code. It feels a bit odd that we are moving arch specific code.
>>>>
>>>> To be honest, I don't quite understand why we need to make the
>>>> diffferentiation on x86. So I guess the first question is how this is
>>>> meant to be used on x86?
>>>
>>> We produce two linker scripts from the single source file: One (with EFI
>>> undefined) to link the ELF binary, and another (with EFI defined) to link
>>> the PE/COFF output. If "EFI" is too imprecise as a name for the identifier,
>>> I wouldn't mind renaming it (to PE_COFF?), but at the same time I'm not
>>> convinced this is really necessary.
>>
>> Thank for the explanation (and the other ones in this thread). You are 
>> right the confusion arised from "generating" vs "linking".
>>
>> Renaming to PE_COFF may help to avoid the confusion with CONFIG_EFI. 
>> That said, it would possibly make more difficult to associate the flag 
>> with "linking an EFI binary".
> 
> Indeed. And EFI_PE_COFF is getting a little unwieldy for my taste.
> 
>> I think some documentaion about the define EFI would be help so there 
>> are no more confusion between CONFIG_EFI/EFI. But I am not sure where to 
>> put it. Maybe at the top of the header?
> 
> That's perhaps the best place, yes.
> 
In this case how about the following comment at the top of xen.lds.h:

"To avoid any confusion about EFI macro used in this header vs EFI support,
the former is used when linking a native EFI (i.e. PE/COFF) binary, whereas
the latter means support for generating EFI binary. Currently EFI macro is
only defined by x86 to link PE/COFF output, however it is not unique to this
architecture."

> Jan
> 

Cheers,
Michal


  reply	other threads:[~2022-03-30 11:04 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-03-22  8:02 [PATCH v2 0/2] xen: Linker scripts synchronization Michal Orzel
2022-03-22  8:02 ` [PATCH v2 1/2] xen: Introduce a header to store common linker scripts content Michal Orzel
2022-03-29  9:06   ` Jan Beulich
2022-03-22  8:02 ` [PATCH v2 2/2] xen: Populate xen.lds.h and make use of its macros Michal Orzel
2022-03-29  9:22   ` Jan Beulich
2022-03-29  9:37     ` Michal Orzel
2022-03-29 10:31       ` Jan Beulich
2022-03-29  9:54   ` Julien Grall
2022-03-29 10:12     ` Michal Orzel
2022-03-29 10:54       ` Julien Grall
2022-03-29 11:09         ` Michal Orzel
2022-03-29 11:42         ` Jan Beulich
2022-03-30 10:32           ` Julien Grall
2022-03-30 10:42             ` Jan Beulich
2022-03-30 11:04               ` Michal Orzel [this message]
2022-03-30 11:57                 ` Jan Beulich
2022-03-30 12:13                   ` Michal Orzel
2022-03-30 12:53                     ` Jan Beulich
2022-03-30 13:24                       ` Michal Orzel
2022-03-30 13:27                         ` Jan Beulich
2022-03-30 13:30                         ` Julien Grall
2022-03-30 13:36                           ` Jan Beulich
2022-03-30 13:37                             ` Julien Grall
2022-03-29 10:37     ` Jan Beulich
2022-03-29 11:07       ` Julien Grall
2022-03-29 11:38         ` Jan Beulich
2022-03-28 10:31 ` [PATCH v2 0/2] xen: Linker scripts synchronization Michal Orzel
2022-03-28 11:21   ` Jan Beulich

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=ffa0e581-6a32-5c3c-7e63-acd5086c6822@arm.com \
    --to=michal.orzel@arm.com \
    --cc=Volodymyr_Babchuk@epam.com \
    --cc=andrew.cooper3@citrix.com \
    --cc=bertrand.marquis@arm.com \
    --cc=george.dunlap@citrix.com \
    --cc=jbeulich@suse.com \
    --cc=julien@xen.org \
    --cc=roger.pau@citrix.com \
    --cc=sstabellini@kernel.org \
    --cc=wl@xen.org \
    --cc=xen-devel@lists.xenproject.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.