From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x336.google.com (mail-wm1-x336.google.com [IPv6:2a00:1450:4864:20::336]) by sourceware.org (Postfix) with ESMTPS id 3A4D4398D040 for ; Tue, 20 Jul 2021 15:31:39 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3A4D4398D040 Received: by mail-wm1-x336.google.com with SMTP id g8-20020a1c9d080000b02901f13dd1672aso1769812wme.0 for ; Tue, 20 Jul 2021 08:31:39 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=LR6FhGgKZFXI6AbVilsVqj7SIosNkslo1hZegf0cIpE=; b=IRY+cbfZVqzWNCA21rBN5ikxnHv2AB8wBnMzF2l6AIseWVD+BgdfmkDpZh5Z8cCmGx /Z0rFYhAEUXOFz0TSARNKHDbjnF4ryVWsZFPgKg12VSgieCQJhfQ8D2HUQtMagKZksiC vf4ul4Z2HKXsgV22vZzjFTujoa87WMgTy/DvcC/VPkdPvOKUXtK3GBJWrtcF7XLRSnr7 nfGIzEwjpEwgXd2MrJz/WYtYxSm0bDbI05qnhgXjEEkanpbGWvMjo3/z7kr5XZi58VIn L/+Vkw7wrQKzhWcCa66vY+FNjJl2Z11F6uxCDLZVpYer+lEMksxRR78RWuONY0TbY01s UTeg== X-Gm-Message-State: AOAM531NZgJWcjAsWyvyiFMWwCnoFokc8/FKpl8eOu1oqiK5EmjjB8Aj j4tPqpOSANxvvVDgkhKN9Aw= X-Google-Smtp-Source: ABdhPJzxmSoq/d2QRo+2rDgQuhbHbPJGnXH6X7ZCS3Leds5JDbL61RGPqdlNQNPOS12S1P2z00s52Q== X-Received: by 2002:a05:600c:2104:: with SMTP id u4mr32732402wml.45.1626795098268; Tue, 20 Jul 2021 08:31:38 -0700 (PDT) Received: from [192.168.1.214] (host81-138-1-83.in-addr.btopenworld.com. [81.138.1.83]) by smtp.googlemail.com with ESMTPSA id b15sm11173471wru.97.2021.07.20.08.31.37 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 20 Jul 2021 08:31:37 -0700 (PDT) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.4 \(3445.104.21\)) Subject: Re: Disabling TLS address caching to help QEMU on GNU/Linux From: Iain Sandoe In-Reply-To: <87im15qbp3.fsf@oldenburg.str.redhat.com> Date: Tue, 20 Jul 2021 16:31:36 +0100 Cc: gcc@gcc.gnu.org, libc-alpha@sourceware.org, qemu-devel@nongnu.org Content-Transfer-Encoding: quoted-printable Message-Id: <55F007B1-A82C-44CB-8427-750AE5FD963E@googlemail.com> References: <87im15qbp3.fsf@oldenburg.str.redhat.com> To: Florian Weimer X-Mailer: Apple Mail (2.3445.104.21) X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 20 Jul 2021 15:31:40 -0000 Hi Florian, This also affects fibres implementations (both C++ and D ones at least = from discussion with both communities). > On 20 Jul 2021, at 15:52, Florian Weimer via Gcc = wrote: >=20 > Currently, the GNU/Linux ABI does not really specify whether the = thread > pointer (the address of the TCB) may change at a function boundary. >=20 > Traditionally, GCC assumes that the ABI allows caching addresses of > thread-local variables across function calls. Such caching varies in > aggressiveness between targets, probably due to differences in the > choice of -mtls-dialect=3Dgnu and -mtls-dialect=3Dgnu2 as the default = for > the targets. (Caching with -mtls-dialect=3Dgnu2 appears to be more > aggressive.) >=20 > In addition to that, glibc defines errno as this: >=20 > extern int *__errno_location (void) __attribute__ ((__const__)); > #define errno (*__errno_location ()) >=20 > And the const attribute has the side effect of caching the address of > errno within the same stack frame. >=20 > With stackful coroutines, such address caching is only valid if > coroutines are only ever resumed on the same thread on which they were > suspended. (The C++ coroutine implementation is not stackful and is = not > affected by this at the ABI level.) There are C++20 coroutine library writers who want to switch threads in symmetric transfers [ I am not entirely convinced about this at present = and it certainly would be suspect with TLS address caching enabled - since a = TLS pointer could equally be cached in the coroutine frame ]. The C++20 coroutine ABI is silent on such matters (it only describes the visible part of the coroutine frame and the builtins used by the std = library). > Historically, I think we took the > position that cross-thread resumption is undefined. But the ABIs = aren't > crystal-clear on this matter. > One important piece of software for GNU is QEMU (not just for = GNU/Linux, > Hurd development also benefits from virtualization). QEMU uses = stackful > coroutines extensively. There are some hard-to-change code areas = where > resumption happens across threads unfortunately. These increasingly > cause problems with more inlining, inter-procedural analysis, and a > general push towards LTO (which is also needed for some security > hardening features). >=20 > Should the GNU toolchain offer something to help out the QEMU > developers? Maybe GCC could offer an option to disable the caching = for > all TLS models. glibc could detect that mode based on a new > preprocessor macro and adjust its __errno_location declaration and > similar function declarations. There will be a performance impact of > this, of course, but it would make the QEMU usage well-defined (at the > lowest levels). >=20 > If this is a programming model that should be supported, then = restoring > some of the optimizations would be possible, by annotating > context-switching functions and TLS-address-dependent functions. But = I > think QEMU would immediately benefit from just the simple approach = that > disables address caching of TLS variables. IMO the general cases you note above are enough reason to want some mechanism to control this, thanks Iain >=20 > Thanks, > Florian >=20