[PATCH] D103304: Update and improve compiler-rt tests for -mllvm -asan_use_after_return=(never|[runtime]|always).
Kevin Athey via Phabricator via llvm-commits
llvm-commits at lists.llvm.org
Thu Jun 3 09:29:56 PDT 2021
kda added inline comments.
================
Comment at: compiler-rt/lib/asan/asan_interface.inc:17
INTERFACE_FUNCTION(__asan_describe_address)
+INTERFACE_FUNCTION(__asan_detect_use_after_return_always)
INTERFACE_FUNCTION(__asan_exp_load1)
----------------
kda wrote:
> I don't think this is right, but I could not determine a better course of action.
No one complained. I'm leaving it.
================
Comment at: compiler-rt/lib/asan/asan_rtl.cpp:402
+ if (&__asan_detect_use_after_return_always &&
+ __asan_detect_use_after_return_always) {
+ __asan_option_detect_stack_use_after_return = 1;
----------------
morehouse wrote:
> vitalybuka wrote:
> > kda wrote:
> > > morehouse wrote:
> > > > According to the comment above, we should not override the runtime flag when this is 1.
> > > Check the code in AddressSanitizer, this global (__asan_detect_use_after_return_always) is only created when ClUseAfterReturn is set to 2.
> > I guess @morehouse comment is about comment on the line 39.
> > It makes impression that value stored makes a difference, but as we discussed before only presence matters.
> > I would put there just:
> > if __asan_detect_use_after_return_always is defined, runtime must not check detect_stack_use_after_return and create FakeStack
> >
> >
> > We don't expect 0 there
> > ```
> > if (&__asan_detect_use_after_return_always) {
> > CHECK_EQ(1, __asan_detect_use_after_return_always);
> > ```
> Yes my main concern was the inaccurate comment.
>
> But my understanding was that @kda wanted 3 options: always, never, and decided-by-runtime-flag. In that case, we *do* expect a zero value to indicate the "never" option.
Okay, I tried to clear up the comments above. and purged the test for non-zero.
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D103304/new/
https://reviews.llvm.org/D103304
More information about the llvm-commits
mailing list