LGTM, and thanks!
Thu, Apr 8
Thu, Mar 18
Mar 12 2021
Mar 11 2021
Mar 10 2021
Mar 9 2021
When using Ninja, does this mean running a null build is no longer a null build, but it at least always invokes this sub-build? Not saying that's bad, just want to understand the change. What does the output of just "ninja" say in that case?
Keep the PAC in the stack trace and only strip it when necessary like comparing traces, looking up symbols.
Mar 8 2021
I've uploaded a new version of the patch (just moving the definition of HAS_48_BIT_ADDRESS_SPACE outside of the SANITIZER_GO branch). @dyung @jmorse could I ask you to check this patch whether it builds correctly on x86_64/linux? Thanks!
Mar 7 2021
Mar 5 2021
Could we reuse the macros/builtins from https://github.com/llvm/llvm-project/blob/main/compiler-rt/lib/sanitizer_common/sanitizer_ptrauth.h instead? Something like this:
Feb 19 2021
Jan 12 2021
Jan 7 2021
Can you add a comment to the header of the public function that eventually surfaced the "99.0" version (I guess that's GetMacosAlignedVersionInternal)? Something like "might return version 99 in rare cases".
Jan 6 2021
Jan 5 2021
Dec 14 2020
Dec 11 2020
@dvyukov a bit more ping :)
Dec 3 2020
Dec 2 2020
Oct 5 2020
@dvyukov more ping :)
Sep 23 2020
@dvyukov friendly ping :)
Aug 31 2020
Specifically, I don't want to mess with the setup for Android and/or non-Darwin crosscompiling, because I have no way of testing that.
Also, I understand that the code in question isn't best already, but I don't have the bandwidth to refactor and test any more extensive changes. I'm only trying to address the problem of getting -arch arm64 / arm64e passed into tests, otherwise we're testing the wrong thing. Let's focus on that, please.
@dvyukov Any feedback here, or is this OK to go in?
Aug 30 2020
Looks good for get rid of the test failure.
Aug 25 2020
Great finds, thanks! I've updated the missing places. I'm leaving the Go parts alone, for now, as Go isn't using ptrauth.
Aug 21 2020
Definitely agree that this is very annoying to read. I think it would be best if we were able to change the ifdef to use something like “HAS_48_BIT_ADDRESS_SPACE” and compute that bool separately. @yln, @dvyukov WDYT?
Ah, sorry :) The context is that any test config for arm64 or arm64e isn’t getting the right -arch flag passed in.
Aug 19 2020
This looks reasonable, but just for verification, could you post the "before" and "after" of the little shadow map printout from ASAN_OPTIONS=verbosity=1?
Aug 18 2020
Aug 17 2020
If we use #if !SANITIZER_MAC || defined(__MAC_10_14), do we still need the forward declarations and weak_import stuff?
Aug 14 2020
This looks good to me. Note that I was actually suggesting to avoid the dynamic_lookup + forward declare and requiring that the *SDK* is at least 10.14 to run tests (which is separate from your OS version). But this way it's even more compatible, so I think we should go with it.
Aug 13 2020
LGTM. Maybe add an if to check if the 10.14-only API is available and just do nothing in the test otherwise?
Does the testcase actually fail without the code change?
Aug 4 2020
If I read the output right, it seems that even before this change, running with TSan messes up the permissions argument. I think this may be some latent bug in glibc that is only triggered in unusual environments (like TSan). I found this comment at https://lkml.org/lkml/2014/10/30/812:
Aug 1 2020
...and could you also see if perhaps this change helps:
diff --git a/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp b/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp --- a/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp +++ b/compiler-rt/lib/tsan/rtl/tsan_interceptors_posix.cpp @@ -137,7 +137,11 @@ const int PTHREAD_BARRIER_SERIAL_THREAD = -1; #endif const int MAP_FIXED = 0x10; typedef long long_t; +#if SANITIZER_MAC || SANITIZER_FREEBSD || SANITIZER_NETBSD typedef __sanitizer::u16 mode_t; +#else +typedef __sanitizer::u32 mode_t; +#endif
Jul 30 2020
I can provide you access to a PPC64LE machine or I can check the details myself if you can tell me exactly what to do and how.
Would anyone with access to a Linux/PPC64 machine be willing to take a look if the open() syscall is receiving the right value (0600 from the testcase)?
Actually given the symptom, I'm thinking this could be a real problem with the variadic interceptor:
Jul 29 2020
Jul 24 2020
Jul 21 2020
Let's handle simulators separately.
Jul 17 2020
Jul 14 2020
Jun 30 2020
Looks reasonable. Could you check that swift_demangle has been correctly returning NULL for a "long time" (a couple years at least)? I'm asking because we can run on older OS's.
May 1 2020
Overall LGTM - would be great to hear feedback from @eugenis though.