get_gcov_type() vs. -fprofile-update=atomic

[Richard Biener]

On Mon, Aug 9, 2021 at 12:56 PM Sebastian Huber
<sebastian.huber@embedded-brains.de> wrote:
>
> On 09/08/2021 12:22, Richard Biener wrote:
> > On Mon, Aug 9, 2021 at 8:52 AM Sebastian Huber
> > <sebastian.huber@embedded-brains.de>  wrote:
> >> Hello,
> >>
> >> I would like to use gcov for a multi-threaded program running on an SMP
> >> machine using a 32-bit SPARC/LEON3 target. This target supports
> >> HAVE_atomic_compare_and_swapsi but not HAVE_atomic_compare_and_swapdi.
> >> Unfortunately we have:
> >>
> >> /* Return the type node for gcov_type.  */
> >>
> >> tree
> >> get_gcov_type (void)
> >> {
> >>     scalar_int_mode mode
> >>       = smallest_int_mode_for_size (LONG_LONG_TYPE_SIZE > 32 ? 64 : 32);
> >>     return lang_hooks.types.type_for_mode (mode, false);
> >> }
> >>
> >> The long long type is 64-bit, the get_gcov_type() returns a 64-bit type.
> >> This disables the atomic support in tree_profiling().
> >>
> >> For what is the gcov type used? Could we add an option to force it to
> >> 32-bit? What would be the consequences?
> > It's a generic counter used for number of CFG edge traversal tracking.
>
> So I guess if this counter overflows, then you get inconsistent
> coverage/profiling information?

Yes.

> >
> > Can you not implement 64bit atomic support for 32bit SPARC somehow?
>
> The 32-bit SPARC/LEON3 has only a 32-bit compare and swap instruction
> (gcc/config/sparc/sync.md). I don't know how you could implement a
> 64-bit atomic support using this without spin locks (this is how
> libatomic support for RTEMS works).

I see.  Note the above get_gcov_type _could_ use a separate target macro
instead of LONG_LONG_TYPE_SIZE (GCOV_TYPE_SIZE?), that
way targets could opt to use a smaller counter.

Note that it isn't currently feasible to for example use a 32bit gcov type
with =atomic but 64bit with =single since the "ABI" of the gcov data isn't
self-descriptive in this aspect.  But it should be possible to record the
counter size in the meta-data and keep the on-disk format use "big"
counters in theory.

But I guess using 32bit counters on sparc-rtems might be the way to
go ...

Richard.

> --
> embedded brains GmbH
> Herr Sebastian HUBER
> Dornierstr. 4
> 82178 Puchheim
> Germany
> email: sebastian.huber@embedded-brains.de
> phone: +49-89-18 94 741 - 16
> fax:   +49-89-18 94 741 - 08
>
> Registergericht: Amtsgericht München
> Registernummer: HRB 157899
> Vertretungsberechtigte Geschäftsführer: Peter Rasmussen, Thomas Dörfler
> Unsere Datenschutzerklärung finden Sie hier:
> https://embedded-brains.de/datenschutzerklaerung/