From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lj1-x22f.google.com (mail-lj1-x22f.google.com [IPv6:2a00:1450:4864:20::22f]) by sourceware.org (Postfix) with ESMTPS id 269963858D28 for ; Tue, 30 May 2023 11:20:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 269963858D28 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-lj1-x22f.google.com with SMTP id 38308e7fff4ca-2af177f12d1so46554211fa.0 for ; Tue, 30 May 2023 04:20:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1685445600; x=1688037600; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:from:to:cc:subject:date :message-id:reply-to; bh=y9Ns2FdQBMZ8wtdAjbIkqfy4OG+KaRHDwFpPRoP/Hko=; b=gtR55y0Uj58JSdqYSm/39m1xCPrajDCDAV3JrNvBcrssMm6Ul8wAbIXRpeMONKBs2D Cre9ZftUn4ISJCaX6y9Fls2Qe1EngBiYZt7kroBdBBg26QXIvUIKRp6biCZrLZKEP/nT p03ENCR7KNdUPD/ImFrp29O5mSKObIIW3BUyu/MJ4gKfTfOaDR9Dxc1+3OuriX1q7ED4 BYhLVTpg1S0KS43XCdv/TqOHet33Y6D4Y3+GfwAxMG72+5WVKd9auMF0clKyBGbFbDoP G+QRbOEqvxOJ8IDMlGbFSqo3by6cKUpFsGkRa6Yoz7uHgFKubVT6lITPFL4JyL5t8Gsj Vafg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685445600; x=1688037600; h=content-transfer-encoding:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=y9Ns2FdQBMZ8wtdAjbIkqfy4OG+KaRHDwFpPRoP/Hko=; b=ZMdmvLFRs10OoKFB5ULlV4BFjRf2vGHFAah/ZJZJTue3ucyToI6VnQ/+jymaEr1cp1 rUi1qIha+ztw6utph1YKtz7r9ZZy5tuXaw+ZI4Tqsw78Vvm17HM4zI2dZDiEHzwrBjUg K9NO1g56eLb+TQlASKWffd5s1FBH45SioIkIlJWs2CZiSDqG+AirBFojG1SAemqM24o9 L7dARc7Z9IUpTt8j+2oFz/6T8gxp5Bpg2ka1xXti5qXYnVqqZOrD4IJWjbqh/sfxUAld jC0cI55zuyLeaZpMLpZMIMHj94Xb6gLTSaBV0C64qR86POuA1TW9yUkb7PwWPuN4YsGJ OFTw== X-Gm-Message-State: AC+VfDzgx40oTwAs1rbsmpsWhLBmBqUuZfGC27yBc11OORcKsohdFXrg 3GQiWDd8vBdZ0fgOayhR1zBFT+kbp11gDsUOayU= X-Google-Smtp-Source: ACHHUZ5E+l9XvP3lYfW+f0o5IF/99bBChoGLO+7NZmp/TsdEXa8oJS28eJ5d2PgAXyCn0W0xhdMZgKj8tB0JzrUkKuA= X-Received: by 2002:a2e:8245:0:b0:2a8:c87f:d220 with SMTP id j5-20020a2e8245000000b002a8c87fd220mr556670ljh.5.1685445599383; Tue, 30 May 2023 04:19:59 -0700 (PDT) MIME-Version: 1.0 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> <0e95b057-ea2f-91c8-e51b-97b3d018cb31@embedded-brains.de> In-Reply-To: <0e95b057-ea2f-91c8-e51b-97b3d018cb31@embedded-brains.de> From: Richard Biener Date: Tue, 30 May 2023 13:17:46 +0200 Message-ID: Subject: Re: [PATCH] libatomic: Provide gthr.h default implementation To: Sebastian Huber Cc: gcc-patches@gcc.gnu.org Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.5 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,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 Tue, May 30, 2023 at 12:17=E2=80=AFPM Sebastian Huber wrote: > > 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. > > > > 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. > > > > 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 > 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 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 > references if you use -fprofile-update=3Datomic 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.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/