[PATCH] gcov: use mmap pools for KVP.

[Martin Liška]

On 1/22/21 3:10 PM, Jan Hubicka wrote:
>> On Fri, Jan 22, 2021 at 2:42 PM Martin Liška <mliska@suse.cz> wrote:
>>>
>>> On 1/22/21 2:38 PM, Jan Hubicka wrote:
>>>> This looks like reasonable solution for Linux (i was thinking of it too)
>>>> but I wonder what about setups w/o mmap support, like mingw32?
>>>
>>> The code still uses malloc approach then.
>>>
>>>> I think we need some fallback there.  I was wondering if simply
>>>> disabling topn profiling until gcov_init time (where we seems to assume
>>>> that malloc already works) would work in that case.
>>>> We may lose some speculation during program construction, but that does
>>>> not seem very bad...
>>>
>>> This does not help you as we may still potentially call malloc during context
>>> when alternative allocator locks malloc/free functions.
>>>
>>> Note that situation is very rare and assuming mmap seems to me a reasonable.
>>
>> Btw, you may want to copy/split out the code from generic-morestack.c which
>> has a comment
>>
>> /* Some systems use LD_PRELOAD or similar tricks to add hooks to
>>     mmap/munmap.  That breaks this code, because when we call mmap
>> ...
>>    Try to avoid the
>>     problem by calling syscall directly.  We only do this on GNU/Linux
>>     for now, but it should be easy to add support for more systems with
>>     testing.  */
> Fun, but I can imagine people doing that...
>>
>> which suggests that we're going to run into the same issue as with malloc
>> when people profile their mmap hook ...
>>
>> Btw, I wonder if it's possible to bring back the original non-allocated counter
>> mode via some -fXYZ flag and using a different counter kind (so both
>> allocation schemes can co-exist?).  On systems that cannot handle the
>> mmap path we could default to the old scheme.
> 
> It is definitly doable (gcov machinery is quite flexible WRT having more
> types of counters).

Yes, that would introduce back the dropped TOPN counters which I intentionally
dropped.

>  We could however also ask users to either resort to
> -fno-profile-values or implement mmap equivalent ifdefs to libgcov if
> they really care about malloc profiling.

Seems reasonable to me.

Well, the current approach makes some assumptions on mmap (and malloc), but
they seem reasonable to me. I don't expect anybody building Mingw Firefox PGO build,
it's likely unsupported configuration.

Another observation about the tcmalloc 'malloc' implementation. It hangs in a PGO build,
but libgcov would be happy if NULL would be returned.

Martin

> 
> So personally I do not see this as a must feature (and I think Martin
> was really looking forward to drop the former topn profile
> implementation :)
> 
> Another intersting case would be, of course, profiling of kernel...
> 
> Honza
>