| Message ID | 6bea2061-e6df-2cea-4bff-858b0f44a0c2@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | [v2] Arm: constrain {,u}int64_aligned_t in public header | expand |
Hi Jan, > On Sep 5, 2023, at 16:26, Jan Beulich <jbeulich@suse.com> wrote: > > For using a GNU extension, it may not be exposed in general, just like > is done on x86 (except that here we need to also work around not all of > the tool stack actually defining __XEN_TOOLS__). External consumers (not > using gcc or a compatible compiler) need to make this type available up > front (just like we expect {,u}int<N>_t to be supplied) - unlike on x86 > the type is actually needed outside of tools-only interfaces, because > guest handle definitions use it. > > While there also add underscores around "aligned". > > Signed-off-by: Jan Beulich <jbeulich@suse.com> I used the same testing approach to redo the test for v2, and everything works fine this time. Tested-by: Henry Wang <Henry.Wang@arm.com> Kind regards, Henry
On Tue, 5 Sep 2023, Henry Wang wrote: > Hi Jan, > > > On Sep 5, 2023, at 16:26, Jan Beulich <jbeulich@suse.com> wrote: > > > > For using a GNU extension, it may not be exposed in general, just like > > is done on x86 (except that here we need to also work around not all of > > the tool stack actually defining __XEN_TOOLS__). External consumers (not > > using gcc or a compatible compiler) need to make this type available up > > front (just like we expect {,u}int<N>_t to be supplied) - unlike on x86 > > the type is actually needed outside of tools-only interfaces, because > > guest handle definitions use it. > > > > While there also add underscores around "aligned". > > > > Signed-off-by: Jan Beulich <jbeulich@suse.com> > > I used the same testing approach to redo the test for v2, and everything > works fine this time. > > Tested-by: Henry Wang <Henry.Wang@arm.com> Reviewed-by: Stefano Stabellini <sstabellini@kernel.org>
--- a/xen/include/public/arch-arm.h +++ b/xen/include/public/arch-arm.h @@ -152,8 +152,10 @@ #define XEN_HYPERCALL_TAG 0XEA1 -#define int64_aligned_t int64_t __attribute__((aligned(8))) -#define uint64_aligned_t uint64_t __attribute__((aligned(8))) +#if defined(__XEN__) || defined(__XEN_TOOLS__) || defined(__GNUC__) +#define int64_aligned_t int64_t __attribute__((__aligned__(8))) +#define uint64_aligned_t uint64_t __attribute__((__aligned__(8))) +#endif #ifndef __ASSEMBLY__ #define ___DEFINE_XEN_GUEST_HANDLE(name, type) \
For using a GNU extension, it may not be exposed in general, just like is done on x86 (except that here we need to also work around not all of the tool stack actually defining __XEN_TOOLS__). External consumers (not using gcc or a compatible compiler) need to make this type available up front (just like we expect {,u}int<N>_t to be supplied) - unlike on x86 the type is actually needed outside of tools-only interfaces, because guest handle definitions use it. While there also add underscores around "aligned". Signed-off-by: Jan Beulich <jbeulich@suse.com> --- v2: Also check for __GNUC__.