[PATCH] D87120: [HeapProf] Heap profiling runtime support

Vitaly Buka via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Sep 8 13:25:11 PDT 2020


vitalybuka added inline comments.


================
Comment at: compiler-rt/lib/heapprof/heapprof_allocator.cpp:561
+    }
+    if (using_primary_allocator) {
+      CHECK(size);
----------------
tejohnson wrote:
> vitalybuka wrote:
> > tejohnson wrote:
> > > vitalybuka wrote:
> > > > there is also asan specific inconsistency
> > > > primiary/secondary difference is because primiary is reuse redzones and secondary not
> > > > unfortunately asan is the worst example. 
> > > > msan, hwasan and lsan have less unneeded stuff
> > > Can you clarify why this isn't needed here? I do see references to the primary/secondary allocator in both hwasan and lsan. In fact lsan has code that conditionally memsets to 0 if it is from primary (similar to what is further below here in asan).
> > primary vs secondary for asan are result of:
> > 1. right redzone is needed for the secondary - irrelevant here
> > 2. meta[1] contains chunk_beg, but I already removing this part from asan D86932, and explained above how to avoid to use GetMetaData here as well
> BTW I found that the  "meta[0] = size" was removed in D86922, you might want to mark that as a parent to D86932. Question on that though. In D86922 you are using a total of at most 45 bits for holding the size. What is in fact the max size we need to represent?
I guess it's is not a problem for heapprov, it has plenty of bits for full uptr?

I am not sure what is required max size should be. I hope 45bit is enough.
If not, asan has large red zones for large allocations. So I still can avoid using metadata.
Those changes are not realy important for asan. I was fixing bug with lsan, found another one with allot_tid, and metadata patches are just a cleanup.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87120



More information about the llvm-commits mailing list