[PATCH] D44579: [asan] Clean up some confusing code in `test/asan/TestCases/Darwin/segv_read_write.c`

[Dan Liew via Phabricator via llvm-commits]

delcypher added a comment.

In https://reviews.llvm.org/D44579#1160019, @delcypher wrote:

> In https://reviews.llvm.org/D44579#1044875, @eugenis wrote:
>
> > The comment makes sense to me. Writes are instrumented with reads from shadow in ASan. Therefore a write to addr in shadow will result in a read from shadow(addr), which is located in the mprotect-ed shadow gap, and will be reported as a read SEGV, not a write SEGV.
> >
> > mmap() argument change looks fine.
>
>
> Thanks for that explanation. ~~That makes more sense now. I'm going to integrate your explanation into the comment and merge. ~~


Actually now I'm completely confused. Running the test on macOS I observe that

- The Read() function triggers: `The signal is caused by a READ memory access`. The access is on the memory location `p` which indicates the access check instrumentation that reads the shadow passed.
- The Write() function triggers: `The signal is caused by a WRITE memory access`. The access is on the memory location `p` which indicates the access check instrumentation that reads the shadow passed.
- The `Read()` function has instrumentation to read from the shadow to check the access is okay. There are no writes to the shadow in this function.
- The `Write()` function has instrumentation to read from the shadow to check the access is okay. There are no writes to the shadow in this function.
- We do intercept `mmap()` but it doesn't look like we update the shadow memory in the interceptor.
- We don't intercept `munmap()` so we aren't updating the shadow here either.

In light of this the comments do not make sense.

- There are no writes to the shadow (okay there is some instrumentation in main() that looks like its setting up the shadow stack but that seems unrelated). Where are the writes to the shadow mentioned in the comments coming from?
- The comments imply doing a write will result in reporting a read in the SEGV handler. That's not what the test is checking for and is not what I observe when running it.


Repository:
  rCRT Compiler Runtime

https://reviews.llvm.org/D44579