[PATCH] D69265: [scudo][standalone] Consolidate lists

Kostya Kortchinsky via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Fri Oct 25 15:34:03 PDT 2019


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


================
Comment at: lib/scudo/standalone/list.h:17
+// Intrusive POD singly and doubly linked list.
 // An object with all zero fields should represent a valid empty list. clear()
 // should be called on all non-zero-initialized objects before using.
----------------
hctim wrote:
> cryptoad wrote:
> > hctim wrote:
> > > Why does the requirements to call `clear()` exist for non-zero-inited objects? For globally zero-init'ed instances of this object, we don't encounter a perf overhead of having `Size`, `First`, and `Last` be initialised to zero. For non-global instances, we have to call `clear()`, which seems easy to forget, and moving this initialisation into the c'tor doesn't cause any additional overhead (and I'd assume the call is elided, making it faster).
> > > 
> > > It also feels easy to forget to call `clear()`, and if any global objects are moved into static scopage, it may be incredibly hard to patch any instances where `clear()` isn't called.
> > Part of the issue, even with `constexpr explicit` constructors is that `__thread` can't seem to deal with them (as opposed to `thread_local`) and complains about it needing "dynamic initialization". It circles back to the choices made with `init` & `initLinkerInitialized`.
> > While your point makes sense, I don't think I can do it, unless I am missing something which is also very possible.
> So I think I remember the same problem from `gwp_asan`, but it was solved for us by marking the c'tor as `constexpr`.
> 
> https://godbolt.org/z/j1q8uR
> ^ works with constexpr c'tor with `__thread` and `thread_local`, fails for `__thread` if not `constexpr` c'tor. Sounds like this might be the same problem?
I gave a shot earlier to `constexpr` as well without success.
Using a `constexpr explicit` constructor for the lists, it bubbles up to the TSD:
```
.../compiler-rt/lib/scudo/standalone/tsd_exclusive.h:93:28: error: non-local variable ‘scudo::TSDRegistryExT<scudo::Allocator<scudo::DefaultConfig> >::ThreadTSD’ declared ‘__thread’ needs dynamic initialization
 THREADLOCAL TSD<Allocator> TSDRegistryExT<Allocator>::ThreadTSD;
                            ^~~~~~~~~~~~~~~~~~~~~~~~~
.../compiler-rt/lib/scudo/standalone/tsd_exclusive.h:93:28: note: C++11 ‘thread_local’ allows dynamic initialization and destruction
```
Part of the issue is probably that all of the TSD sub components as well as the TSD itself should all have `constexpr` constructors, but that's a rabbit hole I am not keen to look into at this moment.


Repository:
  rCRT Compiler Runtime

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D69265/new/

https://reviews.llvm.org/D69265





More information about the llvm-commits mailing list