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.
