On Tue, May 30, 2023 at 12:17 PM Sebastian Huber <sebastian.hu...@embedded-brains.de> wrote: > > On 30.05.23 11:53, Richard Biener wrote: > > On Tue, May 23, 2023 at 11:28 AM Sebastian Huber > > <sebastian.hu...@embedded-brains.de> wrote: > >> On 10.01.23 16:38, Sebastian Huber wrote: > >>> On 19/12/2022 17:02, Sebastian Huber wrote: > >>>> Build libatomic for all targets. Use gthr.h to provide a default > >>>> implementation. If the thread model is "single", then this > >>>> implementation will > >>>> not work if for example atomic operations are used for thread/interrupt > >>>> synchronization. > >>> Is this and the related -fprofile-update=atomic patch something for GCC > >>> 14? > >> Now that the GCC 14 development is in progress, what about this patch? > > Sorry, there doesn't seem to be a main maintainer for libatomic and your > > patch > > touches targets which didn't have it before. > > > > Can you explain how this affects the ABI of targets not having (needing?!) > > libatomic? It might help if you can say this is still opt-in and targets > > not > > building libatomic right now would not with your patch and targets already > > building libatomic have no changes with your patch. > > > > That said - what kind of ABI implications has providing libatomic support > > for a target that didn't do so before? > > Sorry for the missing context. The root problem I want to solve is > getting gcov support for multi-threaded applications. For this we need > atomic 64-bit operations, see also:
I was aware of the context but still worry about the ABI implications. A target that doesn't build libatomic but would need one currently has "unsupported" (aka fail to link) atomic operations that require libatomic support. After your patch such targets suddenly have a new ABI (and supported atomic ops) - this ABI they need to maintain for compatibility reasons I think but it would be (likely) not documented anywhere. I think that's undesirable, esp. without buy-in from the affected target maintainers. > https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608620.html > > The libatomic patch lets it build for every target. Targets with no > explicit support will use the gthr.h API to provide a default > implementation. > > An alternative would be to use the RTEMS approach which uses the > following API (provided by Newlib <machine/_libatomic.h> for RTEMS): > > #include <sys/cdefs.h> > #include <sys/_types.h> > > __BEGIN_DECLS > > __uint32_t _Libatomic_Protect_start(void *); > > void _Libatomic_Protect_end(void *, __uint32_t); > > void _Libatomic_Lock_n(void *, __size_t); > > void _Libatomic_Unlock_n(void *, __size_t); > > __END_DECLS > > We could also leave libatomic as is, but then you may get unresolved > references if you use -fprofile-update=atomic with the patch mentioned > above. The alternative would be to provide the required subset of atomic library functions from libgcov.a and emit calls to that directly? The locked data isn't part of any ABI so no compatibility guarantee needs to be maintained? 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/
