Re: [Xen-devel] [PATCH v1 7/7] Rename sections for compatibility with -ffunction-sections -fdata-sections

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 06.05.16 at 17:48, <ross.lagerwall@xxxxxxxxxx> wrote:
> When building with -ffunction-sections -fdata-sections, it will generate
> section names like .text.show_handlers and .data.payload_list. These
> sections are in the same namespace as the special sections that Xen
> uses, such as .text.kexec and .data.schedulers. To prevent conflicts,
> prefix Xen's special sections with an extra period.
> 
> The idea for this was taken from a similar patch series applied to the
> Linux kernel by the kSplice folks.

First of all - I disliked this naming when I saw it in Linux, and hence
I dislike it here. These double dots just look odd, and they don't
really guard us against any future naming model gcc or clang may
come up with (nor does any other naming scheme, I agree, but I'd
still like a model not using dots better as being of lower risk collision
wise). Which gets me to the first question: What's really the
problem with names generate with -f{function,data}-sections
colliding with ours? I can't see much going wrong as long as all
objects have their alignment suitably recorded, with a few
exceptions, e.g. ...

> --- a/xen/arch/arm/xen.lds.S
> +++ b/xen/arch/arm/xen.lds.S
> @@ -74,11 +74,11 @@ SECTIONS
>  
>    .data : {                    /* Data */
>         . = ALIGN(PAGE_SIZE);
> -       *(.data.page_aligned)
> +       *(.data..page_aligned)
>         *(.data)
>         . = ALIGN(8);
>         __start_schedulers_array = .;
> -       *(.data.schedulers)
> +       *(.data..schedulers)
>         __end_schedulers_array = .;

... things getting enclosed in labels.

>         *(.data.rel)

Why is .data.rel not an issue? A writable global variable named "rel"
would end up in a section named .data.rel with -fdata-sections. IOW
it may well be that a single .lds file serving both purposes can't be
used, unless you want to communicate the use of
-f{function,data}-sections here to make such directives conditional.

> @@ -173,15 +173,15 @@ SECTIONS
>  
>    .bss : {                     /* BSS */
>         __bss_start = .;
> -       *(.bss.stack_aligned)
> +       *(.bss..stack_aligned)
>         . = ALIGN(PAGE_SIZE);
> -       *(.bss.page_aligned)
> +       *(.bss..page_aligned)
>         *(.bss)
>         . = ALIGN(SMP_CACHE_BYTES);
>         __per_cpu_start = .;
> -       *(.bss.percpu)
> +       *(.bss..percpu)
>         . = ALIGN(SMP_CACHE_BYTES);
> -       *(.bss.percpu.read_mostly)
> +       *(.bss..percpu.read_mostly)

Nor do I think names which already have a 3rd dot in them are a
problem with the current naming scheme.

> --- a/xen/arch/x86/boot/x86_64.S
> +++ b/xen/arch/x86/boot/x86_64.S
> @@ -51,7 +51,7 @@ GLOBAL(gdt_descr)
>  GLOBAL(stack_start)
>          .quad   cpu0_stack
>  
> -        .section .data.page_aligned, "aw", @progbits
> +        .section .data..page_aligned, "aw", @progbits

And then, now that you want to go through this exercise and
rename all of them, I think this should be done by introducing a
suitable abstraction, such that another similar rename in the
future can be done by fiddling with a few #define-s in a central
place, without having to go though and touch random sources.
These #define-s could then also be paired with ones usable in
the *.lds files to pick up exactly those section names.

Jan


_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel