https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461
--- Comment #6 from Martin Liška <marxin at gcc dot gnu.org> --- (In reply to Richard Biener from comment #5) > Hmm, is the TOPN allocation strathegy configurable? I wonder whether we have > to resort to an alternate allocation scheme (mmap/sbrk), avoiding libc? No. The only thing we support is a recursive malloc as seen in: ./gcc/testsuite/gcc.dg/tree-prof/indir-call-prof-malloc.c It was added in g:bc2b1a232b1825b421a1aaa21a0865b2d1e4e08c as we use a statically allocated buffer when we recursively entry allocate_gcov_kvp. However this is different as we can't call malloc/calloc from the function as we're in code that initializes a memory allocator. We can mitigate the issue with a pair of new functions __gcov_supress_malloc and __gcov_alloc_malloc that will be called by a custom memory allocator. What do you think about it? > At > least > I don't see a good way to force the gcov allocation to call the libc malloc > rather than a user replacement that is being instrumented. Of course the > instrumentation code could do sth like > > if (is_allocated == 0) > { > is_allocated = in_progress; > ... = malloc (); > is_allocated = 1; > } > else if (is_allocted == in_progress) > { > topn_mem = &transitional_garbage_space; > } > > but of course that's quite some overhead for a small benefit. Maybe it > could be hidden in gcov_malloc.