Re: [PATCH v2 1/2] x86: annotate entry points with type and size
On Tue, May 30, 2023 at 04:23:21PM +0200, Jan Beulich wrote: > On 30.05.2023 15:21, Roger Pau Monné wrote: > > On Tue, May 30, 2023 at 10:06:27AM +0200, Jan Beulich wrote: > >> On 29.05.2023 15:34, Roger Pau Monné wrote: > >>> On Tue, May 23, 2023 at 01:30:51PM +0200, Jan Beulich wrote: > Note that the FB-label in autogen_stubs() cannot be converted just yet: > Such labels cannot be used with .type. We could further diverge from > Linux'es model and avoid setting STT_NOTYPE explicitly (that's the type > labels get by default anyway). > > Note that we can't use ALIGN() (in place of SYM_ALIGN()) as long as we > still have ALIGN. > >>> > >>> FWIW, as I'm looking into using the newly added macros in order to add > >>> annotations suitable for live-patching, I would need to switch some of > >>> the LABEL usages into it's own functions, as it's not possible to > >>> livepatch a function that has labels jumped into from code paths > >>> outside of the function. > >> > >> Hmm, I'm not sure what the best way is to overcome that restriction. I'm > >> not convinced we want to arbitrarily name things "functions". > > > > Any external entry point in the middle of a function-like block will > > prevent it from being live patched. > > Is there actually any particular reason for this restriction? As long > as old and new code has the same external entry points, redirecting > all old ones to their new counterparts would seem feasible. Yes, that was another option, we could force asm patching to always be done with a jump (instead of in-place) and then add jumps at the old entry point addresses in order to redirect to the new addresses. Or assert that the addresses of any symbols inside the function is not changed in order to do in-place replacement of code. > > If you want I can try to do a pass on top of your patch and see how > > that would end up looking. I'm attempting to think about other > > solutions, but every other solution seems quite horrible. > > Right, but splitting functions into piecemeal fragments isn't going > to be very nice either. I'm not sure how much splitting would be required TBH. > + > +#define FUNC(name, algn...) \ > +SYM(name, FUNC, GLOBAL, LAST(16, ## algn), 0x90) > >>> > >>> A rant, should the alignment of functions use a different padding? > >>> (ie: ret or ud2?) In order to prevent stray jumps falling in the > >>> padding and fall trough into the next function. That would also > >>> prevent the implicit fall trough used in some places. > >> > >> Yes, but that's a separate topic (for which iirc patches are pending > >> as well, just of course not integrated with the work here. There's > >> the slight risk of overlooking some "fall-through" case ... > > > > Oh, OK, wasn't aware patches are floating for this already, just came > > across it while reviewing. > > Well, those don't cover padding yet, but they deal with straight-line > speculation past RET or JMP. Introducing the helpers does make it easy to convert the padding for all the existing users at least. > sti > call do_softirq > jmp compat_test_all_events > > -ALIGN > /* %rbx: struct vcpu, %rdx: struct trap_bounce */ > -.Lcompat_process_trapbounce: > +LABEL_LOCAL(.Lcompat_process_trapbounce) > >>> > >>> It's my understanding that here the '.L' prefix is pointless, since > >>> LABEL_LOCAL() will forcefully create a symbol for the label due to the > >>> usage of .type? > >> > >> I don't think .type has this effect. There's certainly no such label in > >> the symbol table of the object file I have as a result. > > > > I was expecting .type to force the creation of a symbol, so the '.L' > > prefix does prevent the symbol from being created even if .type is > > specified. > > > > Shouldn't the assembler complain that we are attempting to set a type > > for a not present symbol? > > But .L symbols are still normal symbols to gas, just that it knows to not > emit them to the symbol table (unless there's a need, e.g. through a use > in a relocation that cannot be expressed as section-relative one). It > could flag the pointless use, but then it may get this wrong if in the > end the symbol does need emitting. Thanks for the explanation. Roger.
Re: [PATCH v2 1/2] x86: annotate entry points with type and size
On 30.05.2023 15:21, Roger Pau Monné wrote: > On Tue, May 30, 2023 at 10:06:27AM +0200, Jan Beulich wrote: >> On 29.05.2023 15:34, Roger Pau Monné wrote: >>> On Tue, May 23, 2023 at 01:30:51PM +0200, Jan Beulich wrote: Note that the FB-label in autogen_stubs() cannot be converted just yet: Such labels cannot be used with .type. We could further diverge from Linux'es model and avoid setting STT_NOTYPE explicitly (that's the type labels get by default anyway). Note that we can't use ALIGN() (in place of SYM_ALIGN()) as long as we still have ALIGN. >>> >>> FWIW, as I'm looking into using the newly added macros in order to add >>> annotations suitable for live-patching, I would need to switch some of >>> the LABEL usages into it's own functions, as it's not possible to >>> livepatch a function that has labels jumped into from code paths >>> outside of the function. >> >> Hmm, I'm not sure what the best way is to overcome that restriction. I'm >> not convinced we want to arbitrarily name things "functions". > > Any external entry point in the middle of a function-like block will > prevent it from being live patched. Is there actually any particular reason for this restriction? As long as old and new code has the same external entry points, redirecting all old ones to their new counterparts would seem feasible. > If you want I can try to do a pass on top of your patch and see how > that would end up looking. I'm attempting to think about other > solutions, but every other solution seems quite horrible. Right, but splitting functions into piecemeal fragments isn't going to be very nice either. --- a/xen/arch/x86/include/asm/asm_defns.h +++ b/xen/arch/x86/include/asm/asm_defns.h @@ -81,6 +81,45 @@ register unsigned long current_stack_poi #ifdef __ASSEMBLY__ +#define SYM_ALIGN(algn...) .balign algn + +#define SYM_L_GLOBAL(name) .globl name +#define SYM_L_WEAK(name) .weak name >>> >>> Won't this better be added when required? I can't spot any weak >>> symbols in assembly ATM, and you don't introduce any _WEAK macro >>> variants below. >> >> Well, Andrew specifically mentioned to desire to also have Linux'es >> support for weak symbols. Hence I decided to add it here despite >> (for now) being unused). I can certainly drop that again, but in >> particular if we wanted to use the scheme globally, I think we may >> want to make it "complete". > > OK, as long as we know it's unused. I've added a sentence to this effect to the description. +#define SYM_L_LOCAL(name) /* nothing */ + +#define SYM_T_FUNC STT_FUNC +#define SYM_T_DATA STT_OBJECT +#define SYM_T_NONE STT_NOTYPE + +#define SYM(name, typ, linkage, algn...) \ +.type name, SYM_T_ ## typ;\ +SYM_L_ ## linkage(name); \ +SYM_ALIGN(algn); \ +name: + +#define END(name) .size name, . - name + +#define ARG1_(x, y...) (x) +#define ARG2_(x, y...) ARG1_(y) + +#define LAST__(nr) ARG ## nr ## _ +#define LAST_(nr) LAST__(nr) +#define LAST(x, y...) LAST_(count_args(x, ## y))(x, ## y) >>> >>> I find LAST not very descriptive, won't it better be named OPTIONAL() >>> or similar? (and maybe placed in lib.h?) >> >> I don't think OPTIONAL describes the purpose. I truly mean "last" here. >> As to placing in lib.h - perhaps, but then we may want to have forms >> with more than 2 arguments right away (and it would be a little unclear >> how far up to go). > > Hm, I would be fine with adding that version with just 2 arguments, as > it's better to have the helper in a generic place IMO. I'll think about this some more. + +#define FUNC(name, algn...) \ +SYM(name, FUNC, GLOBAL, LAST(16, ## algn), 0x90) >>> >>> A rant, should the alignment of functions use a different padding? >>> (ie: ret or ud2?) In order to prevent stray jumps falling in the >>> padding and fall trough into the next function. That would also >>> prevent the implicit fall trough used in some places. >> >> Yes, but that's a separate topic (for which iirc patches are pending >> as well, just of course not integrated with the work here. There's >> the slight risk of overlooking some "fall-through" case ... > > Oh, OK, wasn't aware patches are floating for this already, just came > across it while reviewing. Well, those don't cover padding yet, but they deal with straight-line speculation past RET or JMP. sti call do_softirq jmp compat_test_all_events -ALIGN /* %rbx: struct vcpu, %rdx: struct trap_bounce */ -.Lcompat_process_trapbounce: +LABEL_LOCAL(.Lcompat_process_trapbounce) >>> >>> It's my understanding that here the '.L' prefix is pointless, since >>> LABEL_LOCAL() will forcefully create a
Re: [PATCH v2 1/2] x86: annotate entry points with type and size
On Tue, May 30, 2023 at 10:06:27AM +0200, Jan Beulich wrote: > On 29.05.2023 15:34, Roger Pau Monné wrote: > > On Tue, May 23, 2023 at 01:30:51PM +0200, Jan Beulich wrote: > >> Note that the FB-label in autogen_stubs() cannot be converted just yet: > >> Such labels cannot be used with .type. We could further diverge from > >> Linux'es model and avoid setting STT_NOTYPE explicitly (that's the type > >> labels get by default anyway). > >> > >> Note that we can't use ALIGN() (in place of SYM_ALIGN()) as long as we > >> still have ALIGN. > > > > FWIW, as I'm looking into using the newly added macros in order to add > > annotations suitable for live-patching, I would need to switch some of > > the LABEL usages into it's own functions, as it's not possible to > > livepatch a function that has labels jumped into from code paths > > outside of the function. > > Hmm, I'm not sure what the best way is to overcome that restriction. I'm > not convinced we want to arbitrarily name things "functions". Any external entry point in the middle of a function-like block will prevent it from being live patched. If you want I can try to do a pass on top of your patch and see how that would end up looking. I'm attempting to think about other solutions, but every other solution seems quite horrible. > >> --- a/xen/arch/x86/include/asm/asm_defns.h > >> +++ b/xen/arch/x86/include/asm/asm_defns.h > >> @@ -81,6 +81,45 @@ register unsigned long current_stack_poi > >> > >> #ifdef __ASSEMBLY__ > >> > >> +#define SYM_ALIGN(algn...) .balign algn > >> + > >> +#define SYM_L_GLOBAL(name) .globl name > >> +#define SYM_L_WEAK(name) .weak name > > > > Won't this better be added when required? I can't spot any weak > > symbols in assembly ATM, and you don't introduce any _WEAK macro > > variants below. > > Well, Andrew specifically mentioned to desire to also have Linux'es > support for weak symbols. Hence I decided to add it here despite > (for now) being unused). I can certainly drop that again, but in > particular if we wanted to use the scheme globally, I think we may > want to make it "complete". OK, as long as we know it's unused. > >> +#define SYM_L_LOCAL(name) /* nothing */ > >> + > >> +#define SYM_T_FUNC STT_FUNC > >> +#define SYM_T_DATA STT_OBJECT > >> +#define SYM_T_NONE STT_NOTYPE > >> + > >> +#define SYM(name, typ, linkage, algn...) \ > >> +.type name, SYM_T_ ## typ;\ > >> +SYM_L_ ## linkage(name); \ > >> +SYM_ALIGN(algn); \ > >> +name: > >> + > >> +#define END(name) .size name, . - name > >> + > >> +#define ARG1_(x, y...) (x) > >> +#define ARG2_(x, y...) ARG1_(y) > >> + > >> +#define LAST__(nr) ARG ## nr ## _ > >> +#define LAST_(nr) LAST__(nr) > >> +#define LAST(x, y...) LAST_(count_args(x, ## y))(x, ## y) > > > > I find LAST not very descriptive, won't it better be named OPTIONAL() > > or similar? (and maybe placed in lib.h?) > > I don't think OPTIONAL describes the purpose. I truly mean "last" here. > As to placing in lib.h - perhaps, but then we may want to have forms > with more than 2 arguments right away (and it would be a little unclear > how far up to go). Hm, I would be fine with adding that version with just 2 arguments, as it's better to have the helper in a generic place IMO. > >> + > >> +#define FUNC(name, algn...) \ > >> +SYM(name, FUNC, GLOBAL, LAST(16, ## algn), 0x90) > > > > A rant, should the alignment of functions use a different padding? > > (ie: ret or ud2?) In order to prevent stray jumps falling in the > > padding and fall trough into the next function. That would also > > prevent the implicit fall trough used in some places. > > Yes, but that's a separate topic (for which iirc patches are pending > as well, just of course not integrated with the work here. There's > the slight risk of overlooking some "fall-through" case ... Oh, OK, wasn't aware patches are floating for this already, just came across it while reviewing. > >> --- a/xen/arch/x86/x86_64/compat/entry.S > >> +++ b/xen/arch/x86/x86_64/compat/entry.S > >> @@ -8,10 +8,11 @@ > >> #include > >> #include > >> #include > >> +#include > > > > Shouldn't the inclusion of lib.h be in asm_defs.h, as that's where the > > usage of count_args() resides? (I assume that's why lib.h is added > > here). > > When the uses are in macros I'm always largely undecided, and I slightly > tend towards the (in general, perhaps not overly relevant here) "less > dependencies" solution. As in: Source files not using the macros which > use count_args() also don't need libs.h then. I tend to prefer headers to be self contained, as it overall leads to a clearer set of includes in source files. It's not obvious why entry.S needs lib.h unless the asm_macros.h usage is taken into account. > >> sti > >> call do_softirq > >> jmp compat_test_all_events > >> > >> -ALIGN > >>
Re: [PATCH v2 1/2] x86: annotate entry points with type and size
On 29.05.2023 15:34, Roger Pau Monné wrote: > On Tue, May 23, 2023 at 01:30:51PM +0200, Jan Beulich wrote: >> Note that the FB-label in autogen_stubs() cannot be converted just yet: >> Such labels cannot be used with .type. We could further diverge from >> Linux'es model and avoid setting STT_NOTYPE explicitly (that's the type >> labels get by default anyway). >> >> Note that we can't use ALIGN() (in place of SYM_ALIGN()) as long as we >> still have ALIGN. > > FWIW, as I'm looking into using the newly added macros in order to add > annotations suitable for live-patching, I would need to switch some of > the LABEL usages into it's own functions, as it's not possible to > livepatch a function that has labels jumped into from code paths > outside of the function. Hmm, I'm not sure what the best way is to overcome that restriction. I'm not convinced we want to arbitrarily name things "functions". >> --- a/xen/arch/x86/include/asm/asm_defns.h >> +++ b/xen/arch/x86/include/asm/asm_defns.h >> @@ -81,6 +81,45 @@ register unsigned long current_stack_poi >> >> #ifdef __ASSEMBLY__ >> >> +#define SYM_ALIGN(algn...) .balign algn >> + >> +#define SYM_L_GLOBAL(name) .globl name >> +#define SYM_L_WEAK(name) .weak name > > Won't this better be added when required? I can't spot any weak > symbols in assembly ATM, and you don't introduce any _WEAK macro > variants below. Well, Andrew specifically mentioned to desire to also have Linux'es support for weak symbols. Hence I decided to add it here despite (for now) being unused). I can certainly drop that again, but in particular if we wanted to use the scheme globally, I think we may want to make it "complete". >> +#define SYM_L_LOCAL(name) /* nothing */ >> + >> +#define SYM_T_FUNC STT_FUNC >> +#define SYM_T_DATA STT_OBJECT >> +#define SYM_T_NONE STT_NOTYPE >> + >> +#define SYM(name, typ, linkage, algn...) \ >> +.type name, SYM_T_ ## typ;\ >> +SYM_L_ ## linkage(name); \ >> +SYM_ALIGN(algn); \ >> +name: >> + >> +#define END(name) .size name, . - name >> + >> +#define ARG1_(x, y...) (x) >> +#define ARG2_(x, y...) ARG1_(y) >> + >> +#define LAST__(nr) ARG ## nr ## _ >> +#define LAST_(nr) LAST__(nr) >> +#define LAST(x, y...) LAST_(count_args(x, ## y))(x, ## y) > > I find LAST not very descriptive, won't it better be named OPTIONAL() > or similar? (and maybe placed in lib.h?) I don't think OPTIONAL describes the purpose. I truly mean "last" here. As to placing in lib.h - perhaps, but then we may want to have forms with more than 2 arguments right away (and it would be a little unclear how far up to go). >> + >> +#define FUNC(name, algn...) \ >> +SYM(name, FUNC, GLOBAL, LAST(16, ## algn), 0x90) > > A rant, should the alignment of functions use a different padding? > (ie: ret or ud2?) In order to prevent stray jumps falling in the > padding and fall trough into the next function. That would also > prevent the implicit fall trough used in some places. Yes, but that's a separate topic (for which iirc patches are pending as well, just of course not integrated with the work here. There's the slight risk of overlooking some "fall-through" case ... >> +#define LABEL(name, algn...) \ >> +SYM(name, NONE, GLOBAL, LAST(16, ## algn), 0x90) >> +#define DATA(name, algn...) \ >> +SYM(name, DATA, GLOBAL, LAST(0, ## algn), 0xff) >> + >> +#define FUNC_LOCAL(name, algn...) \ >> +SYM(name, FUNC, LOCAL, LAST(16, ## algn), 0x90) >> +#define LABEL_LOCAL(name, algn...) \ >> +SYM(name, NONE, LOCAL, LAST(16, ## algn), 0x90) > > Is there much value in adding local labels to the symbol table? > > AFAICT the main purpose of this macro is to be used to declare aligned > labels, and here avoid the ALIGN + label name pair, but could likely > drop the .type directive? Right, .type ... NOTYPE is kind of redundant, but it fits the model better here. >> --- a/xen/arch/x86/x86_64/compat/entry.S >> +++ b/xen/arch/x86/x86_64/compat/entry.S >> @@ -8,10 +8,11 @@ >> #include >> #include >> #include >> +#include > > Shouldn't the inclusion of lib.h be in asm_defs.h, as that's where the > usage of count_args() resides? (I assume that's why lib.h is added > here). When the uses are in macros I'm always largely undecided, and I slightly tend towards the (in general, perhaps not overly relevant here) "less dependencies" solution. As in: Source files not using the macros which use count_args() also don't need libs.h then. >> @@ -66,24 +68,21 @@ compat_test_guest_events: >> call compat_create_bounce_frame >> jmp compat_test_all_events >> >> -ALIGN >> /* %rbx: struct vcpu */ >> -compat_process_softirqs: >> +LABEL_LOCAL(compat_process_softirqs) > > Shouldn't this be a local function rather than a local label? It's > fully isolated. I guess it would create issues with > compat_process_trap, as we would
Re: [PATCH v2 1/2] x86: annotate entry points with type and size
On Tue, May 23, 2023 at 01:30:51PM +0200, Jan Beulich wrote:
> Recent gas versions generate minimalistic Dwarf debug info for items
> annotated as functions and having their sizes specified [1]. "Borrow"
> Arm's END() and (remotely) derive other annotation infrastructure from
> Linux'es.
>
> For switch_to_kernel() and restore_all_guest() so far implicit alignment
> (from being first in their respective sections) is being made explicit
> (as in: using FUNC() without 2nd argument). Whereas for
> {,compat}create_bounce_frame() and autogen_entrypoints[] alignment is
> newly arranged for.
>
> Except for the added alignment padding (including their knock-on
> effects) no change in generated code/data.
>
> Signed-off-by: Jan Beulich
>
> [1]
> https://sourceware.org/git?p=binutils-gdb.git;a=commitdiff;h=591cc9fbbfd6d51131c0f1d4a92e7893edcc7a28
> ---
> v2: Full rework.
> ---
> Only two of the assembly files are being converted for now. More could
> be done right here or as follow-on in separate patches.
>
> In principle the framework should be possible to use by other
> architectures as well. If we want this, the main questions are going to
> be:
> - What header file name? (I don't really like Linux'es linkage.h, so I'd
> prefer e.g. asm-defns.h or asm_defns.h as we already have in x86.)
> - How much per-arch customization do we want to permit up front (i.e.
> without knowing how much of it is going to be needed)? Initially I'd
> expect only the default function alignment (and padding) to require
> per-arch definitions.
>
> Note that the FB-label in autogen_stubs() cannot be converted just yet:
> Such labels cannot be used with .type. We could further diverge from
> Linux'es model and avoid setting STT_NOTYPE explicitly (that's the type
> labels get by default anyway).
>
> Note that we can't use ALIGN() (in place of SYM_ALIGN()) as long as we
> still have ALIGN.
FWIW, as I'm looking into using the newly added macros in order to add
annotations suitable for live-patching, I would need to switch some of
the LABEL usages into it's own functions, as it's not possible to
livepatch a function that has labels jumped into from code paths
outside of the function.
> --- a/xen/arch/x86/include/asm/asm_defns.h
> +++ b/xen/arch/x86/include/asm/asm_defns.h
> @@ -81,6 +81,45 @@ register unsigned long current_stack_poi
>
> #ifdef __ASSEMBLY__
>
> +#define SYM_ALIGN(algn...) .balign algn
> +
> +#define SYM_L_GLOBAL(name) .globl name
> +#define SYM_L_WEAK(name) .weak name
Won't this better be added when required? I can't spot any weak
symbols in assembly ATM, and you don't introduce any _WEAK macro
variants below.
> +#define SYM_L_LOCAL(name) /* nothing */
> +
> +#define SYM_T_FUNC STT_FUNC
> +#define SYM_T_DATA STT_OBJECT
> +#define SYM_T_NONE STT_NOTYPE
> +
> +#define SYM(name, typ, linkage, algn...) \
> +.type name, SYM_T_ ## typ;\
> +SYM_L_ ## linkage(name); \
> +SYM_ALIGN(algn); \
> +name:
> +
> +#define END(name) .size name, . - name
> +
> +#define ARG1_(x, y...) (x)
> +#define ARG2_(x, y...) ARG1_(y)
> +
> +#define LAST__(nr) ARG ## nr ## _
> +#define LAST_(nr) LAST__(nr)
> +#define LAST(x, y...) LAST_(count_args(x, ## y))(x, ## y)
I find LAST not very descriptive, won't it better be named OPTIONAL()
or similar? (and maybe placed in lib.h?)
> +
> +#define FUNC(name, algn...) \
> +SYM(name, FUNC, GLOBAL, LAST(16, ## algn), 0x90)
A rant, should the alignment of functions use a different padding?
(ie: ret or ud2?) In order to prevent stray jumps falling in the
padding and fall trough into the next function. That would also
prevent the implicit fall trough used in some places.
> +#define LABEL(name, algn...) \
> +SYM(name, NONE, GLOBAL, LAST(16, ## algn), 0x90)
> +#define DATA(name, algn...) \
> +SYM(name, DATA, GLOBAL, LAST(0, ## algn), 0xff)
> +
> +#define FUNC_LOCAL(name, algn...) \
> +SYM(name, FUNC, LOCAL, LAST(16, ## algn), 0x90)
> +#define LABEL_LOCAL(name, algn...) \
> +SYM(name, NONE, LOCAL, LAST(16, ## algn), 0x90)
Is there much value in adding local labels to the symbol table?
AFAICT the main purpose of this macro is to be used to declare aligned
labels, and here avoid the ALIGN + label name pair, but could likely
drop the .type directive?
> +#define DATA_LOCAL(name, algn...) \
> +SYM(name, DATA, LOCAL, LAST(0, ## algn), 0xff)
> +
> #ifdef HAVE_AS_QUOTED_SYM
> #define SUBSECTION_LBL(tag)\
> .ifndef .L.tag;\
> --- a/xen/arch/x86/x86_64/compat/entry.S
> +++ b/xen/arch/x86/x86_64/compat/entry.S
> @@ -8,10 +8,11 @@
> #include
> #include
> #include
> +#include
Shouldn't the inclusion of lib.h be in asm_defs.h, as that's where the
usage of count_args() resides? (I assume that's why lib.h is added
here).
> #include
> #include
>
>
[PATCH v2 1/2] x86: annotate entry points with type and size
Recent gas versions generate minimalistic Dwarf debug info for items
annotated as functions and having their sizes specified [1]. "Borrow"
Arm's END() and (remotely) derive other annotation infrastructure from
Linux'es.
For switch_to_kernel() and restore_all_guest() so far implicit alignment
(from being first in their respective sections) is being made explicit
(as in: using FUNC() without 2nd argument). Whereas for
{,compat}create_bounce_frame() and autogen_entrypoints[] alignment is
newly arranged for.
Except for the added alignment padding (including their knock-on
effects) no change in generated code/data.
Signed-off-by: Jan Beulich
[1]
https://sourceware.org/git?p=binutils-gdb.git;a=commitdiff;h=591cc9fbbfd6d51131c0f1d4a92e7893edcc7a28
---
v2: Full rework.
---
Only two of the assembly files are being converted for now. More could
be done right here or as follow-on in separate patches.
In principle the framework should be possible to use by other
architectures as well. If we want this, the main questions are going to
be:
- What header file name? (I don't really like Linux'es linkage.h, so I'd
prefer e.g. asm-defns.h or asm_defns.h as we already have in x86.)
- How much per-arch customization do we want to permit up front (i.e.
without knowing how much of it is going to be needed)? Initially I'd
expect only the default function alignment (and padding) to require
per-arch definitions.
Note that the FB-label in autogen_stubs() cannot be converted just yet:
Such labels cannot be used with .type. We could further diverge from
Linux'es model and avoid setting STT_NOTYPE explicitly (that's the type
labels get by default anyway).
Note that we can't use ALIGN() (in place of SYM_ALIGN()) as long as we
still have ALIGN.
--- a/xen/arch/x86/include/asm/asm_defns.h
+++ b/xen/arch/x86/include/asm/asm_defns.h
@@ -81,6 +81,45 @@ register unsigned long current_stack_poi
#ifdef __ASSEMBLY__
+#define SYM_ALIGN(algn...) .balign algn
+
+#define SYM_L_GLOBAL(name) .globl name
+#define SYM_L_WEAK(name) .weak name
+#define SYM_L_LOCAL(name) /* nothing */
+
+#define SYM_T_FUNC STT_FUNC
+#define SYM_T_DATA STT_OBJECT
+#define SYM_T_NONE STT_NOTYPE
+
+#define SYM(name, typ, linkage, algn...) \
+.type name, SYM_T_ ## typ;\
+SYM_L_ ## linkage(name); \
+SYM_ALIGN(algn); \
+name:
+
+#define END(name) .size name, . - name
+
+#define ARG1_(x, y...) (x)
+#define ARG2_(x, y...) ARG1_(y)
+
+#define LAST__(nr) ARG ## nr ## _
+#define LAST_(nr) LAST__(nr)
+#define LAST(x, y...) LAST_(count_args(x, ## y))(x, ## y)
+
+#define FUNC(name, algn...) \
+SYM(name, FUNC, GLOBAL, LAST(16, ## algn), 0x90)
+#define LABEL(name, algn...) \
+SYM(name, NONE, GLOBAL, LAST(16, ## algn), 0x90)
+#define DATA(name, algn...) \
+SYM(name, DATA, GLOBAL, LAST(0, ## algn), 0xff)
+
+#define FUNC_LOCAL(name, algn...) \
+SYM(name, FUNC, LOCAL, LAST(16, ## algn), 0x90)
+#define LABEL_LOCAL(name, algn...) \
+SYM(name, NONE, LOCAL, LAST(16, ## algn), 0x90)
+#define DATA_LOCAL(name, algn...) \
+SYM(name, DATA, LOCAL, LAST(0, ## algn), 0xff)
+
#ifdef HAVE_AS_QUOTED_SYM
#define SUBSECTION_LBL(tag)\
.ifndef .L.tag;\
--- a/xen/arch/x86/x86_64/compat/entry.S
+++ b/xen/arch/x86/x86_64/compat/entry.S
@@ -8,10 +8,11 @@
#include
#include
#include
+#include
#include
#include
-ENTRY(entry_int82)
+FUNC(entry_int82)
ENDBR64
ALTERNATIVE "", clac, X86_FEATURE_XEN_SMAP
pushq $0
@@ -27,9 +28,10 @@ ENTRY(entry_int82)
mov %rsp, %rdi
call do_entry_int82
+END(entry_int82)
/* %rbx: struct vcpu */
-ENTRY(compat_test_all_events)
+FUNC(compat_test_all_events)
ASSERT_NOT_IN_ATOMIC
cli # tests must not race interrupts
/*compat_test_softirqs:*/
@@ -66,24 +68,21 @@ compat_test_guest_events:
call compat_create_bounce_frame
jmp compat_test_all_events
-ALIGN
/* %rbx: struct vcpu */
-compat_process_softirqs:
+LABEL_LOCAL(compat_process_softirqs)
sti
call do_softirq
jmp compat_test_all_events
-ALIGN
/* %rbx: struct vcpu, %rdx: struct trap_bounce */
-.Lcompat_process_trapbounce:
+LABEL_LOCAL(.Lcompat_process_trapbounce)
sti
.Lcompat_bounce_exception:
call compat_create_bounce_frame
jmp compat_test_all_events
- ALIGN
/* %rbx: struct vcpu */
-compat_process_mce:
+LABEL_LOCAL(compat_process_mce)
testb $1 << VCPU_TRAP_MCE,VCPU_async_exception_mask(%rbx)
jnz .Lcompat_test_guest_nmi
sti
@@ -97,9 +96,8 @@ compat_process_mce:
movb %dl,VCPU_async_exception_mask(%rbx)
jmp compat_process_trap
- ALIGN
/* %rbx: struct vcpu */
-compat_process_nmi:
+LABEL_LOCAL(compat_process_nmi)
