[PATCH] D31947: [scudo] Android support groundwork

Kostya Kortchinsky via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Mon Apr 17 14:24:54 PDT 2017


cryptoad marked an inline comment as done.
cryptoad added inline comments.


================
Comment at: lib/scudo/scudo_allocator.cpp:317
+                 bool ForceZeroContents = false) {
+    initThreadMaybe();
+    if (UNLIKELY(!IsPowerOfTwo(Alignment))) {
----------------
eugenis wrote:
> cryptoad wrote:
> > eugenis wrote:
> > > Calling initThreadMaybe() from all entry points looks error-prone. Is it ok (performance-wise) to do lazy initialization in getCurrentThreadContext?
> > Things like BackendAllocator.ReturnNullOrDieOnBadRequest will require initialization, but are called prior to getCurrentThreadContext.
> > I am also actually not super happy about the way this turned out. The alternative would be a preinit or equivalent?
> Ideally access to the allocator cache should go through ThreadLocalContext as well. Maybe.
> 
> What do you mean by preinit?
Access to the local cache & quarantine cache go through the thread context.
The issue I think is more about the global init, which is currently called via a pthread_once in the thread init.
So realistically, the global init doesn't happen until a thread has been initialized.
Unfortunately, that means all the options for the backend haven't been parsed yet if we wait to get the thread context (unless I move it up the code).
I was thinking like in ASan, where it could be initialized once and for all via the preinit_array?


https://reviews.llvm.org/D31947





More information about the llvm-commits mailing list