[PATCH] D54469: Introduce new `disable_init` ASan option that is only supported on platforms where `SANITIZER_SUPPORTS_DISABLED_INIT` is true. Currently this is only supported on Darwin.

[Dan Liew via Phabricator via llvm-commits]

delcypher added a comment.

In https://reviews.llvm.org/D54469#1298884, @kcc wrote:

> > When the ASan library gets loaded we don't want any of the interceptors to be used. The actual purpose of being to load the ASan library this way is simply so we gain access to the ASan malloc enumerator implementation.
>
> I am more confused now.


Sorry. I will try to explain.

> What exactly do you call the "ASan malloc enumerator"?

The "ASan malloc enumerator" in this context means the code that exists in the ASan library that knows how the enumerate the allocations of another process that is using ASan's allocator, i.e. this is the out-of-process allocator enumeration implementation that we are currently trying to land in https://reviews.llvm.org/D53975 .

> Why is it going to work when the allocations come from a non-asan allocator?

Because the intention (when all the ASan malloc enumerator patches land) is that when we call functions in the dlopen()-ed ASan shared library, we will be asking it inspect **a different process** (one that is using ASan for all allocations), not ourselves.
This is the model that memory analysis tools on Darwin follow. Let's say you have a program `foo_asan` running that is built with ASan and you want to use the Darwin `leaks` programs to inspect it. When you launch leaks and tell it to inspect `foo_asan` it would do the following.

1. Freeze `foo_asan` so that all threads stop rusnning (similar to LSan's stop-the-world)
2. `leaks` then examines the `foo_asan` process and figures out what allocator implementation is being used. In this case it is ASan.
3. `leaks` then calls `dlopen()` on the ASan shared library that `foo_asan` is using.
4. `leaks` then finds a special function inside the ASan shared library that knows how to enumerate the allocations of a process using ASan.
5. `leaks` calls this special function, telling it to examine the frozen `foo_asan` program on its behalf.
6. After the special function is finished, leaks then unfreezes `foo_asan` allowing it to continue executing.

What this patch is doing is enabling step 3., in this process. Making it possible to `dlopen()` the ASan shared library without triggering its usual initialisation process because the usual initialisation process would abort the `leaks` process.

This patch doesn't explicitly mention any of this because the feature is adding is not specific to ASan allocator enumeration at all. It is simply trying to make it possible to load the ASan shared library via `dlopen()` and call some functions inside it. Our end goal is of course to get out-of-process ASan allocator enumeration working. However knowing this is not required to understand what this patch is doing. Of course knowing this answers why we are trying to add this feature.

Does this make sense now?


Repository:
  rCRT Compiler Runtime

https://reviews.llvm.org/D54469