On 1/22/21 3:10 PM, Jan Hubicka wrote:
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).
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
