[compiler-rt] [compiler-rt][asan] _aligned_malloc/_aligned_free interception. (PR #82049)

[via llvm-commits]

================
@@ -33,6 +33,14 @@ int test_function() {
     return __LINE__;
   _aligned_free(p);
 
+  char *y = (char *)malloc(1024);
+  char *u = (char *)realloc(y, 2048);
+  u[0] = 'a';
+  _aligned_free(u);
+  // CHECK: AddressSanitizer: attempting free on address which was not malloc()-ed: [[ADDR]] in thread T0
+  u = (char *)_aligned_offset_malloc(1024, 8, 2);
+  _aligned_free(u);
+
----------------
zmodem wrote:

Did you check locally whether this builds and passes the tests? (I didn't try it yet.)

> I'm not sure why I didn't see it before, and I'm also not sure why we get link error for these _aligned functions, but not regular malloc etc. Maybe they're declared different in the CRT somehow.

Thinking more about this:

- The reason why I didn't see it before is that it didn't fail before we added the call to `_aligned_offset_malloc`. Since that's not defined in the asan runtime, the linker resolves it to the definition in aligned.obj in the ucrt instead, and linking that .obj file causes the multiple symbol errors.
- So defining these in asan_malloc_win.cpp might be fine after all, but as @barcharcraz said, we would need to ensure that we define *all* of the variants.
- For the _dbg variants, we can probably just defer to the non-dbg ones.
- Implementing `_aligned_offset_malloc` seems a bit tricky, it's a strange function.
  - One way would be to allocate some extra bytes, and then return `x = p + N` so that `x + offset` has the right alignment.
  - That means `x` is not the first byte in the allocation, which `_aligned_free` could perhaps handle by checking `__sanitizer_get_allocated_begin`.
  - Or maybe there's some deeper magic we could do with asan's allocator code.

https://github.com/llvm/llvm-project/pull/82049