This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [Patch, AArch64] Enable Address sanitizer and UB sanitizer
- From: Christophe Lyon <christophe dot lyon at linaro dot org>
- To: Marcus Shawcroft <Marcus dot Shawcroft at arm dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, Patch Tracking <patches at linaro dot org>
- Date: Fri, 24 Oct 2014 17:44:37 +0200
- Subject: Re: [Patch, AArch64] Enable Address sanitizer and UB sanitizer
- Authentication-results: sourceware.org; auth=none
- References: <CAKdteOZq5uYm3eGuy=r5E0rjmLNrszUzOPO57cF6ptTsL_mdmw at mail dot gmail dot com> <87zjdmm6st dot fsf at igel dot home> <CAKdteOazwUHbLxPD1KagXZ=41ib_pK9LJVRBJfe+YvdvE3NY_Q at mail dot gmail dot com>
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."