[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Xen-devel] [PATCH v5 01/13] x86: reduce general stack alignment to 8



On Thu, Nov 08, 2018 at 09:05:45AM -0700, Jan Beulich wrote:
> We don't need bigger alignment except when calling EFI boot or runtime
> services functions (and we don't guarantee that either, as explained
> close to the top of xen/common/efi/runtime.c in the struct efi_rs_state
> declaration). Hence if the compiler supports reducing stack alignment
> from the ABI compatible 16 bytes (gcc 7 and newer), do so wherever
> possible.
> 
> The EFI case itself is largely dealt with already (actually forcing
> 32-byte alignment) as a result of commit f6b7fedc89 ("x86/EFI: meet
> further spec requirements for runtime calls"). However, as explained in
> the description of that earlier change, without using
> -mincoming-stack-boundary=3 (which we don't want) we still have to make
> the compiler assume 16-byte stack boundaries for CUs making EFI calls in
> order to keep the compiler from aligning the stack, but then placing an
> odd number of 8-byte objects on it, resulting in a mis-aligned outgoing
> stack.
> 
> This as a side effect yields some code size reduction, since for a
> number of sufficiently simple non-leaf functions the stack adjustment
> (by 8, when there are no local stack variables at all) gets dropped
> altogether. I notice exceptions though, for example in guest_cpuid(),
> where in a release build gcc 8.2 now decides to set up a frame pointer
> (without ever using %rbp); I consider this a compiler quirk which we
> should leave to the compiler folks to address eventually.
> 
> Signed-off-by: Jan Beulich <jbeulich@xxxxxxxx>
> ---
> v5: New.
> 
> --- a/xen/arch/x86/Rules.mk
> +++ b/xen/arch/x86/Rules.mk
> @@ -51,6 +51,11 @@ CFLAGS += -DCONFIG_INDIRECT_THUNK
>  export CONFIG_INDIRECT_THUNK=y
>  endif
>  
> +# If supported by the compiler, reduce stack alignment to 8 bytes. But allow
> +# this to be overridden elsewhere.
> +$(call cc-option-add,CFLAGS-stack-boundary,CC,-mpreferred-stack-boundary=3)
> +CFLAGS += $(CFLAGS-stack-boundary)
> +
>  # Set up the assembler include path properly for older toolchains.
>  CFLAGS += -Wa,-I$(BASEDIR)/include
>  
> --- a/xen/arch/x86/efi/Makefile
> +++ b/xen/arch/x86/efi/Makefile
> @@ -5,7 +5,11 @@ CFLAGS += -fshort-wchar
>  
>  boot.init.o: buildid.o
>  
> +EFIOBJ := boot.init.o compat.o runtime.o
> +
> +$(EFIOBJ): CFLAGS-stack-boundary := -mpreferred-stack-boundary=4

From gcc's manual on -mincoming-stack-boundary:

"Thus calling a function compiled with a higher preferred stack boundary
from a function compiled with a lower preferred stack boundary most
likely misaligns the stack." 

I notice runtime.o now has stack alignment of 2^4 while the rest of xen
has 2^3.

There is at least one example (efi_get_time) that could misalign the
stack. Is that okay?

Wei.

> +
>  obj-y := stub.o
> -obj-$(XEN_BUILD_EFI) := boot.init.o compat.o relocs-dummy.o runtime.o
> +obj-$(XEN_BUILD_EFI) := $(EFIOBJ) relocs-dummy.o
>  extra-$(XEN_BUILD_EFI) += buildid.o
>  nocov-$(XEN_BUILD_EFI) += stub.o
> 
> 
> 
> 

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel

 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.