On 05.09.2024 18:10, Andrew Cooper wrote: > On 05/09/2024 4:42 pm, Jan Beulich wrote: >> On 05.09.2024 15:06, Andrew Cooper wrote: >>> --- a/xen/arch/x86/efi/efi-boot.h >>> +++ b/xen/arch/x86/efi/efi-boot.h >>> @@ -102,9 +102,6 @@ static void __init efi_arch_relocate_image(unsigned >>> long delta) >>> } >>> } >>> >>> -extern const s32 __trampoline_rel_start[], __trampoline_rel_stop[]; >>> -extern const s32 __trampoline_seg_start[], __trampoline_seg_stop[]; >> I'd prefer if these stayed here, leaving the 4 symbols as minimally exposed >> as >> possible. Recall that efi-boot.h isn't really a header in that sense, but >> rather a .c file. Elsewhere we keep decls in .c files when they're used in >> just >> one CU. > > See Frediano's RFC series, which needs to change this in order to move > the 32bit relocation logic from asm to C.
And it moves the declarations to the new .c file. Visibility still limited to that one file. And (afaics) no Misra violation, contrary to what your later reply to Frediano suggests. > The only reason efi-boot.h can get away with this right now is because > the other logic is written entirely in asm. > > > Scope-limiting linker section boundaries more than regular variables is > weird to me. It's not as if they magically take more care to use than > regular variables, and trampoline.h is not a wide scope by any means. It's not "more than", it's "like" (i.e. no matter whether a linker script or assembly is the origin of the symbol). Jan
