pcc added a comment. In D108479#3129577 <https://reviews.llvm.org/D108479#3129577>, @rjmccall wrote:
> In D108479#3129571 <https://reviews.llvm.org/D108479#3129571>, @jrtc27 wrote: > >> For CHERI there's the added complication that descriptors and trampolines >> can exist for security reasons when crossing security domains, and you >> absolutely should not let one compartment get pointers to the entry point of >> another compartment's function. You can hand it out if sealed or the >> permissions are cleared, as then you can't really do anything with it other >> than look at the integer address, but that seems a bit odd. > > That would be consistent with getting an unsigned pointer under pointer > authentication or an address with the THUMB bit potentially stripped: it's > just a raw address that you can't safely call. In any case, I suspect it > would be fine for us to say that we just don't support this builtin when the > target is using weird function pointers unless we have some way to bypass the > special treatment in LLVM. > > I agree that "symbol" address is probably the wrong name. Maybe > `__builtin_function_start` or something like that? But before we go much > further on this, we should get confirmation from Peter that we're targeting > the right design. Having this be defined to return the function body address (and diagnose at compile time if that's not supported) seem like the right design to me, and `__builtin_function_start` sounds like a good name. Here's another example of a potential use case that came up in the course of the PAuth ABI work: testing whether a stack trace contains a particular function: https://cs.android.com/android/platform/superproject/+/master:bionic/tests/execinfo_test.cpp;l=94 I think that no matter whether it's CFI, PAuth, CHERI or anything else, this test would want the address of the real function body. If the test is compiled on a platform where taking the real function body address is unsupported, it would fail at runtime if we just let this be compiled as a no-op, so we should diagnose the issue at compile time where possible. ================ Comment at: clang/test/SemaCXX/builtins.cpp:44 +void a(void) {} +static_assert(__builtin_addressof_nocfi(a) == a, ""); + ---------------- I don't think this should always evaluate to true, should it? Maybe we should forbid these types of comparisons in integral constant expressions? Repository: rG LLVM Github Monorepo CHANGES SINCE LAST ACTION https://reviews.llvm.org/D108479/new/ https://reviews.llvm.org/D108479 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
