| Message ID | ca7a78e5-2ee9-4109-7905-3b9186475f3d@suse.com (mailing list archive) |
|---|---|
| State | New, archived |
| Headers | show |
| Series | x86: make hypervisor build with gcc11 | expand |
On Wed, May 19, 2021 at 11:40 AM Jan Beulich <jbeulich@suse.com> wrote: > > Gcc 11 looks to make incorrect assumptions about valid ranges that > pointers may be used for addressing when they are derived from e.g. a > plain constant. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100680. > > Utilize RELOC_HIDE() to work around the issue, which for x86 manifests > in at least > - mpparse.c:efi_check_config(), > - tboot.c:tboot_probe(), > - tboot.c:tboot_gen_frametable_integrity(), > - x86_emulate.c:x86_emulate() (at -O2 only). > The last case is particularly odd not just because it only triggers at > higher optimization levels, but also because it only affects one of at > least three similar constructs. Various "note" diagnostics claim the > valid index range to be [0, 2⁶³-1]. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> Tested-by: Jason Andryuk <jandryuk@gmail.com> Needed on Fedora 34. Thanks, Jason
On Wed, May 19, 2021 at 05:39:50PM +0200, Jan Beulich wrote: > Gcc 11 looks to make incorrect assumptions about valid ranges that > pointers may be used for addressing when they are derived from e.g. a > plain constant. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100680. > > Utilize RELOC_HIDE() to work around the issue, which for x86 manifests > in at least > - mpparse.c:efi_check_config(), > - tboot.c:tboot_probe(), > - tboot.c:tboot_gen_frametable_integrity(), > - x86_emulate.c:x86_emulate() (at -O2 only). > The last case is particularly odd not just because it only triggers at > higher optimization levels, but also because it only affects one of at > least three similar constructs. Various "note" diagnostics claim the > valid index range to be [0, 2⁶³-1]. > > Signed-off-by: Jan Beulich <jbeulich@suse.com> Acked-by: Roger Pau Monné <roger.pau@citrix.com> This is all quite ugly, but I don't have any recommendation short of getting gcc fixed (or being able to disable those heuristics). > > --- a/tools/tests/x86_emulator/x86-emulate.c > +++ b/tools/tests/x86_emulator/x86-emulate.c > @@ -8,6 +8,13 @@ > > #define ERR_PTR(val) NULL > > +/* See gcc bug 100680, but here don't bother making this version dependent. */ Might be worth also referencing 99578 which seems to be the parent bug? (as 100680 has been closed as a duplicate) Thanks, Roger.
On 27.05.2021 10:48, Roger Pau Monné wrote: > On Wed, May 19, 2021 at 05:39:50PM +0200, Jan Beulich wrote: >> Gcc 11 looks to make incorrect assumptions about valid ranges that >> pointers may be used for addressing when they are derived from e.g. a >> plain constant. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100680. >> >> Utilize RELOC_HIDE() to work around the issue, which for x86 manifests >> in at least >> - mpparse.c:efi_check_config(), >> - tboot.c:tboot_probe(), >> - tboot.c:tboot_gen_frametable_integrity(), >> - x86_emulate.c:x86_emulate() (at -O2 only). >> The last case is particularly odd not just because it only triggers at >> higher optimization levels, but also because it only affects one of at >> least three similar constructs. Various "note" diagnostics claim the >> valid index range to be [0, 2⁶³-1]. >> >> Signed-off-by: Jan Beulich <jbeulich@suse.com> > > Acked-by: Roger Pau Monné <roger.pau@citrix.com> Thanks. > This is all quite ugly, but I don't have any recommendation short of > getting gcc fixed (or being able to disable those heuristics). Indeed. >> --- a/tools/tests/x86_emulator/x86-emulate.c >> +++ b/tools/tests/x86_emulator/x86-emulate.c >> @@ -8,6 +8,13 @@ >> >> #define ERR_PTR(val) NULL >> >> +/* See gcc bug 100680, but here don't bother making this version dependent. */ > > Might be worth also referencing 99578 which seems to be the parent > bug? (as 100680 has been closed as a duplicate) Anyone going there will immediately find the xref to that supposed parent bug. Personally I'm not convinced of it truly being a duplicate. Jan
--- a/tools/tests/x86_emulator/x86-emulate.c +++ b/tools/tests/x86_emulator/x86-emulate.c @@ -8,6 +8,13 @@ #define ERR_PTR(val) NULL +/* See gcc bug 100680, but here don't bother making this version dependent. */ +#define gcc11_wrap(x) ({ \ + unsigned long x_; \ + __asm__ ( "" : "=g" (x_) : "0" (x) ); \ + (typeof(x))x_; \ +}) + #define cpu_has_amd_erratum(nr) 0 #define cpu_has_mpx false #define read_bndcfgu() 0 --- a/xen/arch/x86/x86_emulate/x86_emulate.c +++ b/xen/arch/x86/x86_emulate/x86_emulate.c @@ -726,7 +726,7 @@ union vex { #define copy_VEX(ptr, vex) ({ \ if ( !mode_64bit() ) \ (vex).reg |= 8; \ - (ptr)[0 - PFX_BYTES] = ext < ext_8f08 ? 0xc4 : 0x8f; \ + gcc11_wrap(ptr)[0 - PFX_BYTES] = ext < ext_8f08 ? 0xc4 : 0x8f; \ (ptr)[1 - PFX_BYTES] = (vex).raw[0]; \ (ptr)[2 - PFX_BYTES] = (vex).raw[1]; \ container_of((ptr) + 1 - PFX_BYTES, typeof(vex), raw[0]); \ --- a/xen/include/asm-x86/fixmap.h +++ b/xen/include/asm-x86/fixmap.h @@ -78,7 +78,7 @@ extern void __set_fixmap( #define clear_fixmap(idx) __set_fixmap(idx, 0, 0) -#define __fix_to_virt(x) (FIXADDR_TOP - ((x) << PAGE_SHIFT)) +#define __fix_to_virt(x) gcc11_wrap(FIXADDR_TOP - ((x) << PAGE_SHIFT)) #define __virt_to_fix(x) ((FIXADDR_TOP - ((x)&PAGE_MASK)) >> PAGE_SHIFT) #define fix_to_virt(x) ((void *)__fix_to_virt(x)) --- a/xen/include/xen/compiler.h +++ b/xen/include/xen/compiler.h @@ -140,6 +140,12 @@ __asm__ ("" : "=r"(__ptr) : "0"(ptr)); \ (typeof(ptr)) (__ptr + (off)); }) +#if CONFIG_GCC_VERSION >= 110000 /* See gcc bug 100680. */ +# define gcc11_wrap(x) RELOC_HIDE(x, 0) +#else +# define gcc11_wrap(x) (x) +#endif + #ifdef __GCC_ASM_FLAG_OUTPUTS__ # define ASM_FLAG_OUT(yes, no) yes #else --- a/xen/include/xen/pdx.h +++ b/xen/include/xen/pdx.h @@ -19,7 +19,7 @@ extern u64 pdx_region_mask(u64 base, u64 extern void set_pdx_range(unsigned long smfn, unsigned long emfn); #define page_to_pdx(pg) ((pg) - frame_table) -#define pdx_to_page(pdx) (frame_table + (pdx)) +#define pdx_to_page(pdx) gcc11_wrap(frame_table + (pdx)) bool __mfn_valid(unsigned long mfn);
Gcc 11 looks to make incorrect assumptions about valid ranges that pointers may be used for addressing when they are derived from e.g. a plain constant. See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100680. Utilize RELOC_HIDE() to work around the issue, which for x86 manifests in at least - mpparse.c:efi_check_config(), - tboot.c:tboot_probe(), - tboot.c:tboot_gen_frametable_integrity(), - x86_emulate.c:x86_emulate() (at -O2 only). The last case is particularly odd not just because it only triggers at higher optimization levels, but also because it only affects one of at least three similar constructs. Various "note" diagnostics claim the valid index range to be [0, 2⁶³-1]. Signed-off-by: Jan Beulich <jbeulich@suse.com>