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. */ 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. Richard. > Martin
