Use a struct to represent numerical versions instead of encoding release
names in an enumeration. This avoids the need to extend the enumeration
every time there is a new release.
Details
- Reviewers
kubamracek delcypher kcc eugenis
Diff Detail
- Repository
- rG LLVM Github Monorepo
Event Timeline
LGTM except for a few minor nits.
compiler-rt/lib/sanitizer_common/sanitizer_mac.cpp | ||
---|---|---|
623 | If we're going to use a CHECK here this should be CHECK_EQ so that we get a better error message if the check fails. This is also a behaviour change. Are we happy with faulting here where previously we would just return MACOS_VERSION_UNKNOWN? | |
637 | Nice cleanup! | |
compiler-rt/lib/sanitizer_common/sanitizer_mac.h | ||
56 | Nit: I'm wondering if we should rename GetMacosVersion() given then we use it on platforms that are not macOS? GetMacosAlignedVersion() would be a more accurate name. I know you didn't change this line but given you're having to touch all call sites now would be a good time to re-consider how this function is named. |
compiler-rt/lib/sanitizer_common/sanitizer_mac.cpp | ||
---|---|---|
623 |
Yes, I think so. This asserts that the version string follows the expected format. Note that we already assert on the system call above CHECK_NE(internal_sysctl(...), -1);. Considering this my best guess is that MACOS_VERSION_UNKNOWN is an artifact of the old implementation via enum+switch: there should be a value for the default case. |
compiler-rt/lib/sanitizer_common/sanitizer_mac.cpp | ||
---|---|---|
630 | This makes it easy(-ier) to make a mistake if for some reason some new code tries to check for 10.13.6 - it won't work (this code claims all 10.13.4+ versions are 10.13.4). |
compiler-rt/lib/sanitizer_common/sanitizer_mac.h | ||
---|---|---|
43 | Drop this TODO. There's no "bug" in this code and I don't think we need to make notes for us to adopt new language feature we can't use today. |
compiler-rt/lib/sanitizer_common/sanitizer_mac.cpp | ||
---|---|---|
630 | Good catch! I am assumoing this special mapping should apply for kernel 17.5, as follows: kernel -> macOS 17.4 -> 10.13.4 17.5 -> 10.13.4 17.6 -> 10.13.6 |
// Kernel version 17.5 maps to High Sierra 10.13.4. - if (major == 17 && minor >= 5) + if (major == 17 && minor == 5)
Drop TODO.
compiler-rt/lib/sanitizer_common/sanitizer_mac.cpp | ||
---|---|---|
637 | C++ local statics use __cxa_guard_acquire/release/abort [1]. The implementation in the runtime has different locking strategies; currently a global mutex, in the future "futex"es. So there might be an interaction with TSan. There is a test in the Tsan test suite [1] (still passes for me). [1] https://github.com/llvm/llvm-project/blob/c8ac29ab1d798f16999541cd9f08d58ebaa1b4c1/libcxxabi/src/cxa_guard_impl.h#L546 |
compiler-rt/lib/sanitizer_common/sanitizer_mac.cpp | ||
---|---|---|
637 | Scrap it. I have decided that this change is not worth the risk (possible TSan interactions). I will revert this part to minimize the risk (and diff) of this patch. Thanks Dan for pointing this out! |
LGTM except the issue with 10.13.5.
compiler-rt/lib/sanitizer_common/sanitizer_mac.cpp | ||
---|---|---|
630 | kernel -> macOS 17.4 -> 10.13.4 17.5 -> 10.13.4 17.6 -> 10.13.6 This mapping sounds odd (mapping two different kernel versions to the same macOS version). Can you verify this is correct? It looks like GetMacosAlignedVersion() cannot return MacosVersion(10, 13, 5) even if the host OS was 10.13.5. That doesn't sound right. |
clang-format not found in user's PATH; not linting file.