From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dedi548.your-server.de (dedi548.your-server.de [85.10.215.148]) by sourceware.org (Postfix) with ESMTPS id 0F5783858D20 for ; Tue, 30 May 2023 10:17:50 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0F5783858D20 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=embedded-brains.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=embedded-brains.de Received: from sslproxy03.your-server.de ([88.198.220.132]) by dedi548.your-server.de with esmtpsa (TLS1.3) tls TLS_AES_256_GCM_SHA384 (Exim 4.94.2) (envelope-from ) id 1q3wQG-000HTj-BP; Tue, 30 May 2023 12:17:48 +0200 Received: from [82.100.198.138] (helo=mail.embedded-brains.de) by sslproxy03.your-server.de with esmtpsa (TLSv1.3:TLS_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1q3wQF-0001b4-VM; Tue, 30 May 2023 12:17:47 +0200 Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id A399148015A; Tue, 30 May 2023 12:17:47 +0200 (CEST) Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10032) with ESMTP id B-E-Mo3rD5sC; Tue, 30 May 2023 12:17:47 +0200 (CEST) Received: from localhost (localhost [127.0.0.1]) by mail.embedded-brains.de (Postfix) with ESMTP id 556D448019C; Tue, 30 May 2023 12:17:47 +0200 (CEST) X-Virus-Scanned: amavisd-new at zimbra.eb.localhost Received: from mail.embedded-brains.de ([127.0.0.1]) by localhost (zimbra.eb.localhost [127.0.0.1]) (amavisd-new, port 10026) with ESMTP id E-Bo4797sXBD; Tue, 30 May 2023 12:17:47 +0200 (CEST) Received: from [192.168.96.179] (unknown [192.168.96.179]) by mail.embedded-brains.de (Postfix) with ESMTPSA id 3C7B948015A; Tue, 30 May 2023 12:17:47 +0200 (CEST) Message-ID: <0e95b057-ea2f-91c8-e51b-97b3d018cb31@embedded-brains.de> Date: Tue, 30 May 2023 12:17:47 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Subject: Re: [PATCH] libatomic: Provide gthr.h default implementation Content-Language: en-US To: Richard Biener Cc: gcc-patches@gcc.gnu.org References: <20221219160245.55745-1-sebastian.huber@embedded-brains.de> <9894ac2c-f3b8-fac7-197d-2042fb946240@embedded-brains.de> <1316c42f-a69d-ab56-296e-f617942d4759@embedded-brains.de> From: Sebastian Huber In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Authenticated-Sender: smtp-embedded@poldi-networks.de X-Virus-Scanned: Clear (ClamAV 0.103.8/26923/Tue May 30 09:22:21 2023) X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,KAM_DMARC_STATUS,KAM_SHORT,NICE_REPLY_A,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On 30.05.23 11:53, Richard Biener wrote: > On Tue, May 23, 2023 at 11:28=E2=80=AFAM Sebastian Huber > 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/interr= upt >>>> synchronization. >>> Is this and the related -fprofile-update=3Datomic 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 you= r patch > touches targets which didn't have it before. >=20 > 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 targe= ts not > building libatomic right now would not with your patch and targets alre= ady > building libatomic have no changes with your patch. >=20 > That said - what kind of ABI implications has providing libatomic suppo= rt > for a target that didn't do so before? Sorry for the missing context. The root problem I want to solve is=20 getting gcov support for multi-threaded applications. For this we need=20 atomic 64-bit operations, see also: https://gcc.gnu.org/pipermail/gcc-patches/2022-December/608620.html The libatomic patch lets it build for every target. Targets with no=20 explicit support will use the gthr.h API to provide a default=20 implementation. An alternative would be to use the RTEMS approach which uses the=20 following API (provided by Newlib for RTEMS): #include #include __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=20 references if you use -fprofile-update=3Datomic with the patch mentioned=20 above. --=20 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=C3=BCnchen Registernummer: HRB 157899 Vertretungsberechtigte Gesch=C3=A4ftsf=C3=BChrer: Peter Rasmussen, Thomas= D=C3=B6rfler Unsere Datenschutzerkl=C3=A4rung finden Sie hier: https://embedded-brains.de/datenschutzerklaerung/