> On Fri, Jan 22, 2021 at 2:42 PM Martin Liška <mli...@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). 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. 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
