Re: [PATCH] gcov: use mmap pools for KVP.
> Hello.
>
> AS mentioned here, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461#c25, I
> like
> what Richard suggested. So instead of usage of malloc, we should use mmap
> memory
> chunks that serve as a memory pool for struct gcov_kvp.
>
> Malloc is used as a fallback when mmap is not available. I also drop
> statically
> pre-allocated static pool, mmap solves the root problem.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> PR gcov-profile/97461
> * gcov-io.h (GCOV_PREALLOCATED_KVP): Remove.
>
> libgcc/ChangeLog:
>
> PR gcov-profile/97461
> * config.in: Regenerate.
> * configure: Likewise.
> * configure.ac: Check sys/mman.h header file
> * libgcov-driver.c (struct gcov_kvp): Remove static
> pre-allocated pool and use a dynamic one.
> * libgcov.h (MMAP_CHUNK_SIZE): New.
> (gcov_counter_add): Use mmap to allocate pool for struct
> gcov_kvp.
OK, thanks.
We should be ready to add support for non-mmap targets (especially
mingw).
Honza
> ---
> gcc/gcov-io.h | 3 ---
> libgcc/config.in| 3 +++
> libgcc/configure| 4 ++--
> libgcc/configure.ac | 2 +-
> libgcc/libgcov-driver.c | 11 +++
> libgcc/libgcov.h| 42 -
> 6 files changed, 46 insertions(+), 19 deletions(-)
>
> diff --git a/gcc/gcov-io.h b/gcc/gcov-io.h
> index baed67609e2..75f16a274c7 100644
> --- a/gcc/gcov-io.h
> +++ b/gcc/gcov-io.h
> @@ -292,9 +292,6 @@ GCOV_COUNTERS
> /* Maximum number of tracked TOP N value profiles. */
> #define GCOV_TOPN_MAXIMUM_TRACKED_VALUES 32
> -/* Number of pre-allocated gcov_kvp structures. */
> -#define GCOV_PREALLOCATED_KVP 64
> -
> /* Convert a counter index to a tag. */
> #define GCOV_TAG_FOR_COUNTER(COUNT) \
> (GCOV_TAG_COUNTER_BASE + ((gcov_unsigned_t)(COUNT) << 17))
> diff --git a/libgcc/config.in b/libgcc/config.in
> index 5be5321d258..f93c64a00c3 100644
> --- a/libgcc/config.in
> +++ b/libgcc/config.in
> @@ -49,6 +49,9 @@
> /* Define to 1 if you have the header file. */
> #undef HAVE_SYS_AUXV_H
> +/* Define to 1 if you have the header file. */
> +#undef HAVE_SYS_MMAN_H
> +
> /* Define to 1 if you have the header file. */
> #undef HAVE_SYS_STAT_H
> diff --git a/libgcc/configure b/libgcc/configure
> index 78fc22a5784..dd3afb2c957 100755
> --- a/libgcc/configure
> +++ b/libgcc/configure
> @@ -4458,7 +4458,7 @@ as_fn_arith $ac_cv_sizeof_long_double \* 8 &&
> long_double_type_size=$as_val
> for ac_header in inttypes.h stdint.h stdlib.h ftw.h \
> unistd.h sys/stat.h sys/types.h \
> - string.h strings.h memory.h sys/auxv.h
> + string.h strings.h memory.h sys/auxv.h sys/mman.h
> do :
>as_ac_Header=`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh`
> ac_fn_c_check_header_preproc "$LINENO" "$ac_header" "$as_ac_Header"
> @@ -4913,7 +4913,7 @@ case "$host" in
> case "$enable_cet" in
>auto)
> # Check if target supports multi-byte NOPs
> - # and if assembler supports CET insn.
> + # and if compiler and assembler support CET insn.
> cet_save_CFLAGS="$CFLAGS"
> CFLAGS="$CFLAGS -fcf-protection"
> cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> diff --git a/libgcc/configure.ac b/libgcc/configure.ac
> index ed50c0e9b49..10ffb046415 100644
> --- a/libgcc/configure.ac
> +++ b/libgcc/configure.ac
> @@ -224,7 +224,7 @@ AC_SUBST(long_double_type_size)
> AC_CHECK_HEADERS(inttypes.h stdint.h stdlib.h ftw.h \
> unistd.h sys/stat.h sys/types.h \
> - string.h strings.h memory.h sys/auxv.h)
> + string.h strings.h memory.h sys/auxv.h sys/mman.h)
> AC_HEADER_STDC
> # Check for decimal float support.
> diff --git a/libgcc/libgcov-driver.c b/libgcc/libgcov-driver.c
> index e474e032b54..91462350132 100644
> --- a/libgcc/libgcov-driver.c
> +++ b/libgcc/libgcov-driver.c
> @@ -588,11 +588,14 @@ struct gcov_root __gcov_root;
> struct gcov_master __gcov_master =
>{GCOV_VERSION, 0};
> -/* Pool of pre-allocated gcov_kvp strutures. */
> -struct gcov_kvp __gcov_kvp_pool[GCOV_PREALLOCATED_KVP];
> +/* Dynamic pool for gcov_kvp structures. */
> +struct gcov_kvp *__gcov_kvp_dynamic_pool;
> -/* Index to first free gcov_kvp in the pool. */
> -unsigned __gcov_kvp_pool_index;
> +/* Index into __gcov_kvp_dynamic_pool array. */
> +unsigned __gcov_kvp_dynamic_pool_index;
> +
> +/* Size of _gcov_kvp_dynamic_pool array. */
> +unsigned __gcov_kvp_dynamic_pool_size;
> void
> __gcov_exit (void)
> diff --git a/libgcc/libgcov.h b/libgcc/libgcov.h
> index b4a7e942a7e..e848811d89d 100644
> --- a/libgcc/libgcov.h
> +++ b/libgcc/libgcov.h
> @@ -45,6 +45,10 @@
> #include "libgcc_tm.h"
> #include "gcov.h"
> +#if HAVE_SYS_MMAN_H
> +#include
> +#endif
> +
> #if __CHAR_BIT__ == 8
> typedef unsigned gcov_unsigned_t __attribute__ ((mode (SI)));
> typedef unsigned gcov_position_t
Re: [PATCH] gcov: use mmap pools for KVP.
PING^3 On 2/9/21 9:37 AM, Martin Liška wrote: PING^2 @Honza: ? On 1/29/21 2:33 PM, Martin Liška wrote: PING^1 On 1/25/21 1:51 PM, Martin Liška wrote: On 1/22/21 3:33 PM, Jan Hubicka wrote: 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 bring back topn counters or the easier dominating vlaue ones and add command line option. However perhaps better in long term would be keep adding mmap ifdefs for targets where it is important... Kernel guys seems to be getting on profile feedback with clang, so we should keep in mind posibility of supporting that as well. Sure, that should not be so difficult. They should handle it in their kernel run-time. 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. It is possible to build Firefox with mingw on windows and I would expected feedback to work. https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Compiling_Mozilla_With_Mingw However this is not only about Firefox - we notice problems with Firefox since it is only real word app where we look at PGO more systematically. But we definitly should aim for PGO to be useful for apps of similar complexity. It would be nice to incrase this testing coverage. I see. Another observation about the tcmalloc 'malloc' implementation. It hangs in a PGO build, but libgcov would be happy if NULL would be returned. Yep, I would expect other folks to try to PGO optimize malloc implementations an we could run into variety of issues... Ok, can we go with the suggested mmap patch for now? Thanks, Martin Honza 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
Re: [PATCH] gcov: use mmap pools for KVP.
On Tue, Feb 09, 2021 at 09:37:12AM +0100, Martin Liška wrote: > PING^2 > > @Honza: ? Just concerning Windows (though I don't have access to that OS and can't verify), e.g. https://github.com/m-labs/uclibc-lm32/blob/master/utils/mmap-windows.c contains public domain code to emulate mmap on top of the Windows APIs. Guess it could be simplified (we only need anonymous memory and don't need a mmap emulation, can just call). #include #include HANDLE h = CreateFileMapping (INVALID_HANDLE_VALUE, NULL, PAGE_READWRITE, 0, size, NULL); void *mem = NULL; if (h) mem = MapViewOfFile (h, FILE_MAP_WRITE, 0, 0, size); ... // When done: if (mem) UnmapViewOfFile (mem); if (h) CloseHandle (h); Perhaps ask somebody with access to Windows to verify? Jakub
Re: [PATCH] gcov: use mmap pools for KVP.
PING^2 @Honza: ? On 1/29/21 2:33 PM, Martin Liška wrote: PING^1 On 1/25/21 1:51 PM, Martin Liška wrote: On 1/22/21 3:33 PM, Jan Hubicka wrote: 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 bring back topn counters or the easier dominating vlaue ones and add command line option. However perhaps better in long term would be keep adding mmap ifdefs for targets where it is important... Kernel guys seems to be getting on profile feedback with clang, so we should keep in mind posibility of supporting that as well. Sure, that should not be so difficult. They should handle it in their kernel run-time. 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. It is possible to build Firefox with mingw on windows and I would expected feedback to work. https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Compiling_Mozilla_With_Mingw However this is not only about Firefox - we notice problems with Firefox since it is only real word app where we look at PGO more systematically. But we definitly should aim for PGO to be useful for apps of similar complexity. It would be nice to incrase this testing coverage. I see. Another observation about the tcmalloc 'malloc' implementation. It hangs in a PGO build, but libgcov would be happy if NULL would be returned. Yep, I would expect other folks to try to PGO optimize malloc implementations an we could run into variety of issues... Ok, can we go with the suggested mmap patch for now? Thanks, Martin Honza 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
Re: [PATCH] gcov: use mmap pools for KVP.
PING^1 On 1/25/21 1:51 PM, Martin Liška wrote: On 1/22/21 3:33 PM, Jan Hubicka wrote: 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 bring back topn counters or the easier dominating vlaue ones and add command line option. However perhaps better in long term would be keep adding mmap ifdefs for targets where it is important... Kernel guys seems to be getting on profile feedback with clang, so we should keep in mind posibility of supporting that as well. Sure, that should not be so difficult. They should handle it in their kernel run-time. 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. It is possible to build Firefox with mingw on windows and I would expected feedback to work. https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Compiling_Mozilla_With_Mingw However this is not only about Firefox - we notice problems with Firefox since it is only real word app where we look at PGO more systematically. But we definitly should aim for PGO to be useful for apps of similar complexity. It would be nice to incrase this testing coverage. I see. Another observation about the tcmalloc 'malloc' implementation. It hangs in a PGO build, but libgcov would be happy if NULL would be returned. Yep, I would expect other folks to try to PGO optimize malloc implementations an we could run into variety of issues... Ok, can we go with the suggested mmap patch for now? Thanks, Martin Honza 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
Re: [PATCH] gcov: use mmap pools for KVP.
On 1/22/21 3:33 PM, Jan Hubicka wrote: 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 bring back topn counters or the easier dominating vlaue ones and add command line option. However perhaps better in long term would be keep adding mmap ifdefs for targets where it is important... Kernel guys seems to be getting on profile feedback with clang, so we should keep in mind posibility of supporting that as well. Sure, that should not be so difficult. They should handle it in their kernel run-time. 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. It is possible to build Firefox with mingw on windows and I would expected feedback to work. https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Compiling_Mozilla_With_Mingw However this is not only about Firefox - we notice problems with Firefox since it is only real word app where we look at PGO more systematically. But we definitly should aim for PGO to be useful for apps of similar complexity. It would be nice to incrase this testing coverage. I see. Another observation about the tcmalloc 'malloc' implementation. It hangs in a PGO build, but libgcov would be happy if NULL would be returned. Yep, I would expect other folks to try to PGO optimize malloc implementations an we could run into variety of issues... Ok, can we go with the suggested mmap patch for now? Thanks, Martin Honza 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
Re: [PATCH] gcov: use mmap pools for KVP.
> > 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 bring back topn counters or the easier dominating vlaue ones and add command line option. However perhaps better in long term would be keep adding mmap ifdefs for targets where it is important... Kernel guys seems to be getting on profile feedback with clang, so we should keep in mind posibility of supporting that as well. > > > 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. It is possible to build Firefox with mingw on windows and I would expected feedback to work. https://developer.mozilla.org/en-US/docs/Mozilla/Developer_guide/Build_Instructions/Compiling_Mozilla_With_Mingw However this is not only about Firefox - we notice problems with Firefox since it is only real word app where we look at PGO more systematically. But we definitly should aim for PGO to be useful for apps of similar complexity. It would be nice to incrase this testing coverage. > > Another observation about the tcmalloc 'malloc' implementation. It hangs in a > PGO build, > but libgcov would be happy if NULL would be returned. Yep, I would expect other folks to try to PGO optimize malloc implementations an we could run into variety of issues... Honza > > 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 > > >
Re: [PATCH] gcov: use mmap pools for KVP.
On 1/22/21 3:10 PM, Jan Hubicka wrote: On Fri, Jan 22, 2021 at 2:42 PM Martin Liška 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
Re: [PATCH] gcov: use mmap pools for KVP.
> On Fri, Jan 22, 2021 at 2:42 PM Martin Liška 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
Re: [PATCH] gcov: use mmap pools for KVP.
On Fri, Jan 22, 2021 at 2:42 PM Martin Liška 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
Re: [PATCH] gcov: use mmap pools for KVP.
> 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. I defnitly like using mmap since it should be quite robust on Posix platforms. However we essentially make it impossible to build firefox with profile feedback on Windows with jemalloc profilled, for example? I am not sure how deeply we care and I am sure Mingw must have way to implement memory allocation by hand as well, so we can just be ready to add more ifdef for targets where this become an issue. It would be nice to add some documentation of it, since the hang is very non-obvious, but I do not know if we have good place for this. Honza
Re: [PATCH] gcov: use mmap pools for KVP.
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. Martin
Re: [PATCH] gcov: use mmap pools for KVP.
> Hello.
>
> AS mentioned here, https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97461#c25, I
> like
> what Richard suggested. So instead of usage of malloc, we should use mmap
> memory
> chunks that serve as a memory pool for struct gcov_kvp.
>
> Malloc is used as a fallback when mmap is not available. I also drop
> statically
> pre-allocated static pool, mmap solves the root problem.
>
> Patch can bootstrap on x86_64-linux-gnu and survives regression tests.
>
> Ready to be installed?
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?
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...
Honza
> Thanks,
> Martin
>
> gcc/ChangeLog:
>
> PR gcov-profile/97461
> * gcov-io.h (GCOV_PREALLOCATED_KVP): Remove.
>
> libgcc/ChangeLog:
>
> PR gcov-profile/97461
> * config.in: Regenerate.
> * configure: Likewise.
> * configure.ac: Check sys/mman.h header file
> * libgcov-driver.c (struct gcov_kvp): Remove static
> pre-allocated pool and use a dynamic one.
> * libgcov.h (MMAP_CHUNK_SIZE): New.
> (gcov_counter_add): Use mmap to allocate pool for struct
> gcov_kvp.
> ---
> gcc/gcov-io.h | 3 ---
> libgcc/config.in| 3 +++
> libgcc/configure| 4 ++--
> libgcc/configure.ac | 2 +-
> libgcc/libgcov-driver.c | 11 +++
> libgcc/libgcov.h| 42 -
> 6 files changed, 46 insertions(+), 19 deletions(-)
>
> diff --git a/gcc/gcov-io.h b/gcc/gcov-io.h
> index baed67609e2..75f16a274c7 100644
> --- a/gcc/gcov-io.h
> +++ b/gcc/gcov-io.h
> @@ -292,9 +292,6 @@ GCOV_COUNTERS
> /* Maximum number of tracked TOP N value profiles. */
> #define GCOV_TOPN_MAXIMUM_TRACKED_VALUES 32
> -/* Number of pre-allocated gcov_kvp structures. */
> -#define GCOV_PREALLOCATED_KVP 64
> -
> /* Convert a counter index to a tag. */
> #define GCOV_TAG_FOR_COUNTER(COUNT) \
> (GCOV_TAG_COUNTER_BASE + ((gcov_unsigned_t)(COUNT) << 17))
> diff --git a/libgcc/config.in b/libgcc/config.in
> index 5be5321d258..f93c64a00c3 100644
> --- a/libgcc/config.in
> +++ b/libgcc/config.in
> @@ -49,6 +49,9 @@
> /* Define to 1 if you have the header file. */
> #undef HAVE_SYS_AUXV_H
> +/* Define to 1 if you have the header file. */
> +#undef HAVE_SYS_MMAN_H
> +
> /* Define to 1 if you have the header file. */
> #undef HAVE_SYS_STAT_H
> diff --git a/libgcc/configure b/libgcc/configure
> index 78fc22a5784..dd3afb2c957 100755
> --- a/libgcc/configure
> +++ b/libgcc/configure
> @@ -4458,7 +4458,7 @@ as_fn_arith $ac_cv_sizeof_long_double \* 8 &&
> long_double_type_size=$as_val
> for ac_header in inttypes.h stdint.h stdlib.h ftw.h \
> unistd.h sys/stat.h sys/types.h \
> - string.h strings.h memory.h sys/auxv.h
> + string.h strings.h memory.h sys/auxv.h sys/mman.h
> do :
>as_ac_Header=`$as_echo "ac_cv_header_$ac_header" | $as_tr_sh`
> ac_fn_c_check_header_preproc "$LINENO" "$ac_header" "$as_ac_Header"
> @@ -4913,7 +4913,7 @@ case "$host" in
> case "$enable_cet" in
>auto)
> # Check if target supports multi-byte NOPs
> - # and if assembler supports CET insn.
> + # and if compiler and assembler support CET insn.
> cet_save_CFLAGS="$CFLAGS"
> CFLAGS="$CFLAGS -fcf-protection"
> cat confdefs.h - <<_ACEOF >conftest.$ac_ext
> diff --git a/libgcc/configure.ac b/libgcc/configure.ac
> index ed50c0e9b49..10ffb046415 100644
> --- a/libgcc/configure.ac
> +++ b/libgcc/configure.ac
> @@ -224,7 +224,7 @@ AC_SUBST(long_double_type_size)
> AC_CHECK_HEADERS(inttypes.h stdint.h stdlib.h ftw.h \
> unistd.h sys/stat.h sys/types.h \
> - string.h strings.h memory.h sys/auxv.h)
> + string.h strings.h memory.h sys/auxv.h sys/mman.h)
> AC_HEADER_STDC
> # Check for decimal float support.
> diff --git a/libgcc/libgcov-driver.c b/libgcc/libgcov-driver.c
> index e474e032b54..91462350132 100644
> --- a/libgcc/libgcov-driver.c
> +++ b/libgcc/libgcov-driver.c
> @@ -588,11 +588,14 @@ struct gcov_root __gcov_root;
> struct gcov_master __gcov_master =
>{GCOV_VERSION, 0};
> -/* Pool of pre-allocated gcov_kvp strutures. */
> -struct gcov_kvp __gcov_kvp_pool[GCOV_PREALLOCATED_KVP];
> +/* Dynamic pool for gcov_kvp structures. */
> +struct gcov_kvp *__gcov_kvp_dynamic_pool;
> -/* Index to first free gcov_kvp in the pool. */
> -unsigned __gcov_kvp_pool_index;
> +/* Index into __gcov_kvp_dynamic_pool array. */
> +unsigned __gcov_kvp_dynamic_pool_index;
> +
> +/* Size of _gcov_kvp_dynamic_pool array. */
> +unsigned __gcov_kvp_dynamic_pool_size;
> void
> __gcov_exit (void)
> diff --git a/libgcc/libgcov.h b/libgcc/libgcov.h
>
