On 25.09.2024 18:08, oleksii.kuroc...@gmail.com wrote:
> On Wed, 2024-09-25 at 10:36 +0200, Jan Beulich wrote:
>> PPC's desire to use DECL_SECTION() can certainly be covered by
>> providing
>> a (trivial) DECL_SECTION() also for Arm and RISC-V. Seeing that even
>> x86
>> overrides the default to the trivial form for building xen.efi, I'm
>> inclined to suggest we should actually have a way for an arch to
>> indicate
>> to xen.lds.h that it wants just the trivial form (avoiding a later
>> #undef).
> If to go with what I suggested before then x86 will look like:
> 
> diff --git a/xen/arch/x86/xen.lds.S b/xen/arch/x86/xen.lds.S
> index d48de67cfd..911585541e 100644
> --- a/xen/arch/x86/xen.lds.S
> +++ b/xen/arch/x86/xen.lds.S
> @@ -3,6 +3,10 @@
>  
>  #include <xen/cache.h>
>  #include <xen/lib.h>
> +
> +#ifdef EFI
> +#define SIMPLE_DECL_SECTION
> +#endif
>  #include <xen/xen.lds.h>
>  #include <asm/page.h>
>  #undef ENTRY
> @@ -12,9 +16,7 @@
>  
>  #define FORMAT "pei-x86-64"
>  #undef __XEN_VIRT_START
> -#undef DECL_SECTION
>  #define __XEN_VIRT_START __image_base__
> -#define DECL_SECTION(x) x :
>  
>  ENTRY(efi_start)
>  
> diff --git a/xen/include/xen/xen.lds.h b/xen/include/xen/xen.lds.h
> index a17810bb28..fb11ba7357 100644
> --- a/xen/include/xen/xen.lds.h
> +++ b/xen/include/xen/xen.lds.h
> @@ -5,6 +5,8 @@
>   * Common macros to be used in architecture specific linker scripts.
>   */
>  
> +#ifdef SIMPLE_DECL_SECTION

#ifndef I guess?

> @@ -15,6 +17,10 @@
>  # define DECL_SECTION(x) x : AT(ADDR(x) - __XEN_VIRT_START)
>  #endif
>  
> +#else /* SIMPLE_DECL_SECION */
> +# define DECL_SECTION(x) x :
> +#endif
> +
>  /*
>   * To avoid any confusion, please note that the EFI macro does not
> correspond
>   * to EFI support and is used when linking a native EFI (i.e. PE/COFF)
> binary,
> 
> Does it make sense? Or it would be better to follow way for each
> architecture:
>    #undef DECL_SECTION
>    #define DECL_SECTION(x) x :

Hard to tell which one's better; I was asking myself that same question
when writing an earlier reply. I'm slightly in favor of the form you have
now.

Jan

Reply via email to