On Mon, Aug 9, 2021 at 12:56 PM Sebastian Huber
<sebastian.hu...@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.hu...@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.hu...@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/
