On 16.12.22 13:09, Richard Biener wrote:
On Fri, Dec 16, 2022 at 11:39 AM Sebastian Huber
<sebastian.hu...@embedded-brains.de> wrote:
On 16.12.22 10:47, Richard Biener wrote:
No, if you select -fprofile-update=atomic, then the updates shall be
atomic from my point of view. If a fallback is acceptable, then you can
use -fprofile-update=prefer-atomic. Using the fallback in
-fprofile-update=atomic is a bug which prevents the use of gcov for
multi-threaded applications on the lower end targets which do not have
atomic operations in hardware.
Ah, OK. So the fallback there is libatomic calls as well then? Note
not all targets support libatomic, for those the failure mode is likely
a link error (which might be fine, but we eventually might want to
amend documentation to indicate this failure mode).
It seems these library calls caused issues in the past:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77466
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77378
Hmm, those are testsuite-isms in some way but of course
users would run into the same issue, needing explicit
-latomic (where available). I suppose target specs could
automatically add that for -fprofile-update=atomic but this
would need to be specified at link time as well then.
Why can't we provide libatomic for all targets? Is gthr.h not always
available?
One option could be to emit calls to a new libgcov function:
__gcov_inc_counter(counter) -> updated value
This function could use a __gthread_mutex_t mutex for updates. This ends
up probably with quite a bad performance.
But that's eventually what libatomic will do as well as fallback.
For libatomic, hosts can implement a protect_start() and protect_end()
function. On RTEMS, this is implemented like this:
#include <machine/_libatomic.h>
static inline UWORD
protect_start (void *ptr)
{
return _Libatomic_Protect_start (ptr);
}
static inline void
protect_end (void *ptr, UWORD isr_level)
{
_Libatomic_Protect_end (ptr, isr_level);
}
On single-core systems, this is mapped to interrupt disable/enable. This
is quite efficient (compared to a mutex).
I don't have a good idea here.
Do you have to explicitely link -latomic on RISCV?
For RTEMS, libatomic is always added to the linker command line:
gcc/config/rtems.h:"%{qrtems:--start-group -lrtemsbsp -lrtemscpu
-latomic -lc -lgcc --end-group}"
For riscv, there seems to be also a linux special case:
gcc/config/riscv/linux.h: " %{pthread:" LD_AS_NEEDED_OPTION " -latomic
" LD_NO_AS_NEEDED_OPTION "}"
gcc/config/riscv/linux.h:#define LIB_SPEC GNU_USER_TARGET_LIB_SPEC "
-latomic "
--
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/
