Message ID | CAKdteOZq5uYm3eGuy=r5E0rjmLNrszUzOPO57cF6ptTsL_mdmw@mail.gmail.com |
---|---|
State | New |
Headers | show |
+static unsigned HOST_WIDE_INT +aarch64_asan_shadow_offset (void) +{ + return (HOST_WIDE_INT_1 << 36); +} + Looking around various other ports I see magic numbers including 29, 41, 44.... Help me understand why 36 is the right choice for aarch64? Cheers /Marcus On 5 September 2014 15:49, Christophe Lyon <christophe.lyon@linaro.org> wrote: > Hi, > > The attached patch enables the address and undefined behavior sanitizers. > > I have tested it on AArch64 hardware, and asan.exp tests pass, but a > few ubsan.exp tests fail as follows: > FAIL: c-c++-common/ubsan/float-cast-overflow-1.c -O3 -g execution test > FAIL: c-c++-common/ubsan/float-cast-overflow-1.c -O2 -flto > -flto-partition=none execution test > FAIL: c-c++-common/ubsan/float-cast-overflow-2.c -O3 -g execution test > FAIL: c-c++-common/ubsan/float-cast-overflow-3.c -O3 -g execution test > FAIL: c-c++-common/ubsan/float-cast-overflow-4.c -O2 execution test > FAIL: c-c++-common/ubsan/float-cast-overflow-4.c -O3 -g execution test > FAIL: c-c++-common/ubsan/overflow-int128.c -O0 (internal compiler error) > FAIL: c-c++-common/ubsan/overflow-int128.c -O0 (test for excess errors) > FAIL: c-c++-common/ubsan/overflow-int128.c -O1 (internal compiler error) > FAIL: c-c++-common/ubsan/overflow-int128.c -O1 (test for excess errors) > FAIL: c-c++-common/ubsan/overflow-int128.c -O2 (internal compiler error) > FAIL: c-c++-common/ubsan/overflow-int128.c -O2 (test for excess errors) > FAIL: c-c++-common/ubsan/overflow-int128.c -O3 -fomit-frame-pointer > (internal compiler error) > FAIL: c-c++-common/ubsan/overflow-int128.c -O3 -fomit-frame-pointer > (test for excess errors) > FAIL: c-c++-common/ubsan/overflow-int128.c -O3 -g (internal compiler error) > FAIL: c-c++-common/ubsan/overflow-int128.c -O3 -g (test for excess errors) > FAIL: c-c++-common/ubsan/overflow-int128.c -Os (internal compiler error) > FAIL: c-c++-common/ubsan/overflow-int128.c -Os (test for excess errors) > FAIL: c-c++-common/ubsan/overflow-int128.c -O2 -flto > -flto-partition=none (internal compiler error) > FAIL: c-c++-common/ubsan/overflow-int128.c -O2 -flto > -flto-partition=none (test for excess errors) > FAIL: c-c++-common/ubsan/overflow-int128.c -O2 -flto (internal > compiler error) > FAIL: c-c++-common/ubsan/overflow-int128.c -O2 -flto (test for excess errors) > FAIL: gcc.dg/ubsan/float-cast-overflow-bf.c -O3 -g execution test > > I think all these failures need to be addressed separately, and should > not prevent from adding the functionality since most of them pass. > > Note that an update of libsanitizer is required, to include at least > revision 209641 (which fixes internal_fork for AArch64). > > OK for trunk? > > Christophe. > > 2014-09-05 Christophe Lyon <christophe.lyon@linaro.org> > gcc/ > * config/aarch64/aarch64-linux.h (ASAN_CC1_SPEC): Define. > (CC1_SPEC): Define. > * config/aarch64/aarch64.c (aarch64_asan_shadow_offset): New function. > (TARGET_ASAN_SHADOW_OFFSET): Define. > > libsanitizer/ > * configure.tgt: Add AArch64 pattern.
> On Sep 9, 2014, at 2:50 AM, Marcus Shawcroft <marcus.shawcroft@gmail.com> wrote: > > +static unsigned HOST_WIDE_INT > +aarch64_asan_shadow_offset (void) > +{ > + return (HOST_WIDE_INT_1 << 36); > +} > + > > Looking around various other ports I see magic numbers including 29, > 41, 44.... Help me understand why 36 is the right choice for aarch64? Also why 36? What is the min virtual address space aarch64 Linux kernel supports with 4k pages and 3 level page table? Also does this need to conditionalized on lp64? Since I am about to post glibc patches turning on address sanitizer breaks that. Thanks, Andrew > > Cheers > /Marcus > > >> On 5 September 2014 15:49, Christophe Lyon <christophe.lyon@linaro.org> wrote: >> Hi, >> >> The attached patch enables the address and undefined behavior sanitizers. >> >> I have tested it on AArch64 hardware, and asan.exp tests pass, but a >> few ubsan.exp tests fail as follows: >> FAIL: c-c++-common/ubsan/float-cast-overflow-1.c -O3 -g execution test >> FAIL: c-c++-common/ubsan/float-cast-overflow-1.c -O2 -flto >> -flto-partition=none execution test >> FAIL: c-c++-common/ubsan/float-cast-overflow-2.c -O3 -g execution test >> FAIL: c-c++-common/ubsan/float-cast-overflow-3.c -O3 -g execution test >> FAIL: c-c++-common/ubsan/float-cast-overflow-4.c -O2 execution test >> FAIL: c-c++-common/ubsan/float-cast-overflow-4.c -O3 -g execution test >> FAIL: c-c++-common/ubsan/overflow-int128.c -O0 (internal compiler error) >> FAIL: c-c++-common/ubsan/overflow-int128.c -O0 (test for excess errors) >> FAIL: c-c++-common/ubsan/overflow-int128.c -O1 (internal compiler error) >> FAIL: c-c++-common/ubsan/overflow-int128.c -O1 (test for excess errors) >> FAIL: c-c++-common/ubsan/overflow-int128.c -O2 (internal compiler error) >> FAIL: c-c++-common/ubsan/overflow-int128.c -O2 (test for excess errors) >> FAIL: c-c++-common/ubsan/overflow-int128.c -O3 -fomit-frame-pointer >> (internal compiler error) >> FAIL: c-c++-common/ubsan/overflow-int128.c -O3 -fomit-frame-pointer >> (test for excess errors) >> FAIL: c-c++-common/ubsan/overflow-int128.c -O3 -g (internal compiler error) >> FAIL: c-c++-common/ubsan/overflow-int128.c -O3 -g (test for excess errors) >> FAIL: c-c++-common/ubsan/overflow-int128.c -Os (internal compiler error) >> FAIL: c-c++-common/ubsan/overflow-int128.c -Os (test for excess errors) >> FAIL: c-c++-common/ubsan/overflow-int128.c -O2 -flto >> -flto-partition=none (internal compiler error) >> FAIL: c-c++-common/ubsan/overflow-int128.c -O2 -flto >> -flto-partition=none (test for excess errors) >> FAIL: c-c++-common/ubsan/overflow-int128.c -O2 -flto (internal >> compiler error) >> FAIL: c-c++-common/ubsan/overflow-int128.c -O2 -flto (test for excess errors) >> FAIL: gcc.dg/ubsan/float-cast-overflow-bf.c -O3 -g execution test >> >> I think all these failures need to be addressed separately, and should >> not prevent from adding the functionality since most of them pass. >> >> Note that an update of libsanitizer is required, to include at least >> revision 209641 (which fixes internal_fork for AArch64). >> >> OK for trunk? >> >> Christophe. >> >> 2014-09-05 Christophe Lyon <christophe.lyon@linaro.org> >> gcc/ >> * config/aarch64/aarch64-linux.h (ASAN_CC1_SPEC): Define. >> (CC1_SPEC): Define. >> * config/aarch64/aarch64.c (aarch64_asan_shadow_offset): New function. >> (TARGET_ASAN_SHADOW_OFFSET): Define. >> >> libsanitizer/ >> * configure.tgt: Add AArch64 pattern.
On 9 September 2014 12:03, <pinskia@gmail.com> wrote: > > >> On Sep 9, 2014, at 2:50 AM, Marcus Shawcroft <marcus.shawcroft@gmail.com> wrote: >> >> +static unsigned HOST_WIDE_INT >> +aarch64_asan_shadow_offset (void) >> +{ >> + return (HOST_WIDE_INT_1 << 36); >> +} >> + >> >> Looking around various other ports I see magic numbers including 29, >> 41, 44.... Help me understand why 36 is the right choice for aarch64? > > Also why 36? What is the min virtual address space aarch64 Linux kernel supports with 4k pages and 3 level page table? Also does this need to conditionalized on lp64? Since I am about to post glibc patches turning on address sanitizer breaks that. > The address space is 2^39 according to /proc/self/maps: [...] The shadow offset is obtained by dividing this value by 8 -> 2^36. Note that this value has to match kAArch64_ShadowOffset64 as defined in libsanitizer/asan/asan_mapping.h. I do expect a followup patch to support ilp32, but I wouldn't post a patch which I haven't tested. Christophe. > Thanks, > Andrew > > > >> >> Cheers >> /Marcus >> >> >>> On 5 September 2014 15:49, Christophe Lyon <christophe.lyon@linaro.org> wrote: >>> Hi, >>> >>> The attached patch enables the address and undefined behavior sanitizers. >>> >>> I have tested it on AArch64 hardware, and asan.exp tests pass, but a >>> few ubsan.exp tests fail as follows: >>> FAIL: c-c++-common/ubsan/float-cast-overflow-1.c -O3 -g execution test >>> FAIL: c-c++-common/ubsan/float-cast-overflow-1.c -O2 -flto >>> -flto-partition=none execution test >>> FAIL: c-c++-common/ubsan/float-cast-overflow-2.c -O3 -g execution test >>> FAIL: c-c++-common/ubsan/float-cast-overflow-3.c -O3 -g execution test >>> FAIL: c-c++-common/ubsan/float-cast-overflow-4.c -O2 execution test >>> FAIL: c-c++-common/ubsan/float-cast-overflow-4.c -O3 -g execution test >>> FAIL: c-c++-common/ubsan/overflow-int128.c -O0 (internal compiler error) >>> FAIL: c-c++-common/ubsan/overflow-int128.c -O0 (test for excess errors) >>> FAIL: c-c++-common/ubsan/overflow-int128.c -O1 (internal compiler error) >>> FAIL: c-c++-common/ubsan/overflow-int128.c -O1 (test for excess errors) >>> FAIL: c-c++-common/ubsan/overflow-int128.c -O2 (internal compiler error) >>> FAIL: c-c++-common/ubsan/overflow-int128.c -O2 (test for excess errors) >>> FAIL: c-c++-common/ubsan/overflow-int128.c -O3 -fomit-frame-pointer >>> (internal compiler error) >>> FAIL: c-c++-common/ubsan/overflow-int128.c -O3 -fomit-frame-pointer >>> (test for excess errors) >>> FAIL: c-c++-common/ubsan/overflow-int128.c -O3 -g (internal compiler error) >>> FAIL: c-c++-common/ubsan/overflow-int128.c -O3 -g (test for excess errors) >>> FAIL: c-c++-common/ubsan/overflow-int128.c -Os (internal compiler error) >>> FAIL: c-c++-common/ubsan/overflow-int128.c -Os (test for excess errors) >>> FAIL: c-c++-common/ubsan/overflow-int128.c -O2 -flto >>> -flto-partition=none (internal compiler error) >>> FAIL: c-c++-common/ubsan/overflow-int128.c -O2 -flto >>> -flto-partition=none (test for excess errors) >>> FAIL: c-c++-common/ubsan/overflow-int128.c -O2 -flto (internal >>> compiler error) >>> FAIL: c-c++-common/ubsan/overflow-int128.c -O2 -flto (test for excess errors) >>> FAIL: gcc.dg/ubsan/float-cast-overflow-bf.c -O3 -g execution test >>> >>> I think all these failures need to be addressed separately, and should >>> not prevent from adding the functionality since most of them pass. >>> >>> Note that an update of libsanitizer is required, to include at least >>> revision 209641 (which fixes internal_fork for AArch64). >>> >>> OK for trunk? >>> >>> Christophe. >>> >>> 2014-09-05 Christophe Lyon <christophe.lyon@linaro.org> >>> gcc/ >>> * config/aarch64/aarch64-linux.h (ASAN_CC1_SPEC): Define. >>> (CC1_SPEC): Define. >>> * config/aarch64/aarch64.c (aarch64_asan_shadow_offset): New function. >>> (TARGET_ASAN_SHADOW_OFFSET): Define. >>> >>> libsanitizer/ >>> * configure.tgt: Add AArch64 pattern.
On 9 September 2014 13:08, Christophe Lyon <christophe.lyon@linaro.org> wrote: > On 9 September 2014 12:03, <pinskia@gmail.com> wrote: >> >> >>> On Sep 9, 2014, at 2:50 AM, Marcus Shawcroft <marcus.shawcroft@gmail.com> wrote: >>> >>> +static unsigned HOST_WIDE_INT >>> +aarch64_asan_shadow_offset (void) >>> +{ >>> + return (HOST_WIDE_INT_1 << 36); >>> +} >>> + >>> >>> Looking around various other ports I see magic numbers including 29, >>> 41, 44.... Help me understand why 36 is the right choice for aarch64? >> >> Also why 36? What is the min virtual address space aarch64 Linux kernel supports with 4k pages and 3 level page table? Also does this need to conditionalized on lp64? Since I am about to post glibc patches turning on address sanitizer breaks that. >> > > The address space is 2^39 according to /proc/self/maps: > [...] > > The shadow offset is obtained by dividing this value by 8 -> 2^36. > > Note that this value has to match kAArch64_ShadowOffset64 as defined > in libsanitizer/asan/asan_mapping.h. > > I do expect a followup patch to support ilp32, but I wouldn't post a > patch which I haven't tested. Presumably for ILP32 the shadow offset should be 1<<29 and we will need to make both asan_mapping.h and aarch64_asan_shadow_offset conditional. This patch for LP64 is OK. Thanks /Marcus
On 17 September 2014 12:48, Marcus Shawcroft <marcus.shawcroft@gmail.com> wrote: > On 9 September 2014 13:08, Christophe Lyon <christophe.lyon@linaro.org> wrote: >> On 9 September 2014 12:03, <pinskia@gmail.com> wrote: >>> >>> >>>> On Sep 9, 2014, at 2:50 AM, Marcus Shawcroft <marcus.shawcroft@gmail.com> wrote: >>>> >>>> +static unsigned HOST_WIDE_INT >>>> +aarch64_asan_shadow_offset (void) >>>> +{ >>>> + return (HOST_WIDE_INT_1 << 36); >>>> +} >>>> + >>>> >>>> Looking around various other ports I see magic numbers including 29, >>>> 41, 44.... Help me understand why 36 is the right choice for aarch64? >>> >>> Also why 36? What is the min virtual address space aarch64 Linux kernel supports with 4k pages and 3 level page table? Also does this need to conditionalized on lp64? Since I am about to post glibc patches turning on address sanitizer breaks that. >>> >> >> The address space is 2^39 according to /proc/self/maps: >> [...] >> >> The shadow offset is obtained by dividing this value by 8 -> 2^36. >> >> Note that this value has to match kAArch64_ShadowOffset64 as defined >> in libsanitizer/asan/asan_mapping.h. >> >> I do expect a followup patch to support ilp32, but I wouldn't post a >> patch which I haven't tested. > > Presumably for ILP32 the shadow offset should be 1<<29 and we will > need to make both asan_mapping.h and aarch64_asan_shadow_offset > conditional. > Indeed. We'll do that once Andrew has committed all his IPL32 patches (glibc). > This patch for LP64 is OK. I will commit it once the libsanitizer runtime has been updated to at least r209641 otherwise GCC will fail to build for AArch64. > Thanks > /Marcus
On 21 September 2014 20:07, Christophe Lyon <christophe.lyon@linaro.org> wrote: > On 17 September 2014 12:48, Marcus Shawcroft <marcus.shawcroft@gmail.com> wrote: >> On 9 September 2014 13:08, Christophe Lyon <christophe.lyon@linaro.org> wrote: >>> On 9 September 2014 12:03, <pinskia@gmail.com> wrote: >>>> >>>> >>>>> On Sep 9, 2014, at 2:50 AM, Marcus Shawcroft <marcus.shawcroft@gmail.com> wrote: >>>>> >>>>> +static unsigned HOST_WIDE_INT >>>>> +aarch64_asan_shadow_offset (void) >>>>> +{ >>>>> + return (HOST_WIDE_INT_1 << 36); >>>>> +} >>>>> + >>>>> >>>>> Looking around various other ports I see magic numbers including 29, >>>>> 41, 44.... Help me understand why 36 is the right choice for aarch64? >>>> >>>> Also why 36? What is the min virtual address space aarch64 Linux kernel supports with 4k pages and 3 level page table? Also does this need to conditionalized on lp64? Since I am about to post glibc patches turning on address sanitizer breaks that. >>>> >>> >>> The address space is 2^39 according to /proc/self/maps: >>> [...] >>> >>> The shadow offset is obtained by dividing this value by 8 -> 2^36. >>> >>> Note that this value has to match kAArch64_ShadowOffset64 as defined >>> in libsanitizer/asan/asan_mapping.h. >>> >>> I do expect a followup patch to support ilp32, but I wouldn't post a >>> patch which I haven't tested. >> >> Presumably for ILP32 the shadow offset should be 1<<29 and we will >> need to make both asan_mapping.h and aarch64_asan_shadow_offset >> conditional. >> > Indeed. We'll do that once Andrew has committed all his IPL32 patches (glibc). > >> This patch for LP64 is OK. > I will commit it once the libsanitizer runtime has been updated to at > least r209641 otherwise GCC will fail to build for AArch64. Committed as r215642. Christophe.
On 26 September 2014 23:05, Andreas Schwab <schwab@linux-m68k.org> wrote: > https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34c65c4 > > * sanitizer_common/sanitizer_platform_limits_posix.h > (__sanitizer___kernel_old_uid_t, __sanitizer___kernel_old_gid_t) > [__aarch64__]: Define to unsigned short. > Thanks for pointing this. My understanding is that this kind of patch has to be submitted to the libsanitizer maintainers via the LLVM project. I'm going to take care of it. Christophe. > --- > libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h > index caa36a4..139fe0a 100644 > --- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h > +++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h > @@ -470,7 +470,7 @@ namespace __sanitizer { > typedef long __sanitizer___kernel_off_t; > #endif > > -#if defined(__powerpc__) || defined(__aarch64__) || defined(__mips__) > +#if defined(__powerpc__) || defined(__mips__) > typedef unsigned int __sanitizer___kernel_old_uid_t; > typedef unsigned int __sanitizer___kernel_old_gid_t; > #else > -- > 2.1.1 > > -- > Andreas Schwab, schwab@linux-m68k.org > GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 > "And now for something completely different."
On 29 September 2014 15:01, Christophe Lyon <christophe.lyon@linaro.org> wrote: > On 26 September 2014 23:05, Andreas Schwab <schwab@linux-m68k.org> wrote: >> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34c65c4 >> >> * sanitizer_common/sanitizer_platform_limits_posix.h >> (__sanitizer___kernel_old_uid_t, __sanitizer___kernel_old_gid_t) >> [__aarch64__]: Define to unsigned short. >> > > Thanks for pointing this. > > My understanding is that this kind of patch has to be submitted to the > libsanitizer maintainers via the LLVM project. > > I'm going to take care of it. > > Christophe. > Hi, Although I tried to speed things up, this patch has not yet made it to GCC trunk, but it has been committed in upstream libsanitizer. While testing a cherry-pick of the relevant commit, I realized that we already have aarch64 machines running older kernels, and applying this patch means GCC would no longer build on such configurations. I'm unsure about the desirable approach: A- modify upsteam libsanitizer so that __sanitizer___kernel_old_[gu]id_t are defined to match the definition of the kernel headers used to build GCC B- drop backward compatibility and make it impossible to build gcc+libsanitizer on aarch64 with a kernel older than 3.15.3 A: means I have to iterate with upstream libsanitizer, to discuss & agree on a patch, then cherry-pick it to GCC B: I can do it now, but since 3.15.3 is rather new, it's a bit harsh for users, and maybe a libsanitizer/configure.tgt update would be desirable to cleanly prevent trying to build libsanitizer in a no longer supported configuration. It also means that binary toolchains have another implicit dependency on the kernel versions (runtime and build-time ones). Thanks, Christophe. >> --- >> libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h | 2 +- >> 1 file changed, 1 insertion(+), 1 deletion(-) >> >> diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h >> index caa36a4..139fe0a 100644 >> --- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h >> +++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h >> @@ -470,7 +470,7 @@ namespace __sanitizer { >> typedef long __sanitizer___kernel_off_t; >> #endif >> >> -#if defined(__powerpc__) || defined(__aarch64__) || defined(__mips__) >> +#if defined(__powerpc__) || defined(__mips__) >> typedef unsigned int __sanitizer___kernel_old_uid_t; >> typedef unsigned int __sanitizer___kernel_old_gid_t; >> #else >> -- >> 2.1.1 >> >> -- >> Andreas Schwab, schwab@linux-m68k.org >> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 >> "And now for something completely different."
On Fri, Oct 24, 2014 at 8:44 AM, Christophe Lyon <christophe.lyon@linaro.org> wrote: > On 29 September 2014 15:01, Christophe Lyon <christophe.lyon@linaro.org> wrote: >> On 26 September 2014 23:05, Andreas Schwab <schwab@linux-m68k.org> wrote: >>> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=34c65c4 >>> >>> * sanitizer_common/sanitizer_platform_limits_posix.h >>> (__sanitizer___kernel_old_uid_t, __sanitizer___kernel_old_gid_t) >>> [__aarch64__]: Define to unsigned short. >>> >> >> Thanks for pointing this. >> >> My understanding is that this kind of patch has to be submitted to the >> libsanitizer maintainers via the LLVM project. >> >> I'm going to take care of it. >> >> Christophe. >> > > Hi, > > Although I tried to speed things up, this patch has not yet made it to > GCC trunk, but it has been committed in upstream libsanitizer. > > While testing a cherry-pick of the relevant commit, I realized that we > already have aarch64 machines running older kernels, and applying this > patch means GCC would no longer build on such configurations. > > I'm unsure about the desirable approach: > A- modify upsteam libsanitizer so that > __sanitizer___kernel_old_[gu]id_t are defined to match the definition > of the kernel headers used to build GCC > B- drop backward compatibility and make it impossible to build > gcc+libsanitizer on aarch64 with a kernel older than 3.15.3 > > A: means I have to iterate with upstream libsanitizer, to discuss & > agree on a patch, then cherry-pick it to GCC > B: I can do it now, but since 3.15.3 is rather new, it's a bit harsh > for users, and maybe a libsanitizer/configure.tgt update would be > desirable to cleanly prevent trying to build libsanitizer in a no > longer supported configuration. > > It also means that binary toolchains have another implicit dependency > on the kernel versions (runtime and build-time ones). The binary toolchain I am not worried about. I and others use either 3.10 or 3.14 since those are the two long term supported kernels. Thanks, Andrew > > > Thanks, > > Christophe. > > > > >>> --- >>> libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h | 2 +- >>> 1 file changed, 1 insertion(+), 1 deletion(-) >>> >>> diff --git a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h >>> index caa36a4..139fe0a 100644 >>> --- a/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h >>> +++ b/libsanitizer/sanitizer_common/sanitizer_platform_limits_posix.h >>> @@ -470,7 +470,7 @@ namespace __sanitizer { >>> typedef long __sanitizer___kernel_off_t; >>> #endif >>> >>> -#if defined(__powerpc__) || defined(__aarch64__) || defined(__mips__) >>> +#if defined(__powerpc__) || defined(__mips__) >>> typedef unsigned int __sanitizer___kernel_old_uid_t; >>> typedef unsigned int __sanitizer___kernel_old_gid_t; >>> #else >>> -- >>> 2.1.1 >>> >>> -- >>> Andreas Schwab, schwab@linux-m68k.org >>> GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 >>> "And now for something completely different."
diff --git a/gcc/config/aarch64/aarch64-linux.h b/gcc/config/aarch64/aarch64-linux.h index 8d20310..2278516 100644 --- a/gcc/config/aarch64/aarch64-linux.h +++ b/gcc/config/aarch64/aarch64-linux.h @@ -23,6 +23,12 @@ #define GLIBC_DYNAMIC_LINKER "/lib/ld-linux-aarch64%{mbig-endian:_be}%{mabi=ilp32:_ilp32}.so.1" +#undef ASAN_CC1_SPEC +#define ASAN_CC1_SPEC "%{%:sanitize(address):-funwind-tables}" + +#undef CC1_SPEC +#define CC1_SPEC GNU_USER_TARGET_CC1_SPEC ASAN_CC1_SPEC + #define CPP_SPEC "%{pthread:-D_REENTRANT}" #define LINUX_TARGET_LINK_SPEC "%{h*} \ diff --git a/gcc/config/aarch64/aarch64.c b/gcc/config/aarch64/aarch64.c index c3c871e..39b9fd2 100644 --- a/gcc/config/aarch64/aarch64.c +++ b/gcc/config/aarch64/aarch64.c @@ -9826,6 +9826,14 @@ aarch64_expand_movmem (rtx *operands) return true; } +/* Implement the TARGET_ASAN_SHADOW_OFFSET hook. */ + +static unsigned HOST_WIDE_INT +aarch64_asan_shadow_offset (void) +{ + return (HOST_WIDE_INT_1 << 36); +} + #undef TARGET_ADDRESS_COST #define TARGET_ADDRESS_COST aarch64_address_cost @@ -10072,6 +10080,9 @@ aarch64_expand_movmem (rtx *operands) #undef TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS #define TARGET_CALL_FUSAGE_CONTAINS_NON_CALLEE_CLOBBERS true +#undef TARGET_ASAN_SHADOW_OFFSET +#define TARGET_ASAN_SHADOW_OFFSET aarch64_asan_shadow_offset + struct gcc_target targetm = TARGET_INITIALIZER; #include "gt-aarch64.h" diff --git a/libsanitizer/configure.tgt b/libsanitizer/configure.tgt index 6de4a65..2c302ab 100644 --- a/libsanitizer/configure.tgt +++ b/libsanitizer/configure.tgt @@ -35,6 +35,8 @@ case "${target}" in ;; arm*-*-linux*) ;; + aarch64*-*-linux*) + ;; x86_64-*-darwin[1]* | i?86-*-darwin[1]*) TSAN_SUPPORTED=no ;;