From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 5D18DC433FE for ; Thu, 17 Feb 2022 15:23:54 +0000 (UTC) Received: from localhost ([::1]:51756 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nKidN-0002GC-Cc for qemu-devel@archiver.kernel.org; Thu, 17 Feb 2022 10:23:53 -0500 Received: from eggs.gnu.org ([209.51.188.92]:52088) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nKiIl-0004c9-N3 for qemu-devel@nongnu.org; Thu, 17 Feb 2022 10:02:36 -0500 Received: from smtp5-g21.free.fr ([212.27.42.5]:48410) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nKiIc-0005og-0O for qemu-devel@nongnu.org; Thu, 17 Feb 2022 10:02:33 -0500 Received: from localhost (unknown [89.217.187.128]) (Authenticated sender: sergesanspaille@free.fr) by smtp5-g21.free.fr (Postfix) with ESMTPSA id 73E5E5FFCF; Thu, 17 Feb 2022 16:02:17 +0100 (CET) Date: Thu, 17 Feb 2022 16:02:16 +0100 From: Serge Guelton To: Paolo Bonzini Subject: Re: Portable inline asm to get address of TLS variable Message-ID: <20220217150216.GD11782@sguelton.remote.csb> References: <87leyaznm6.fsf@oldenburg.str.redhat.com> <877d9uzgsd.fsf@oldenburg.str.redhat.com> <1a17e6e5-fd03-a01b-9692-4dd9d7bffcb0@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1a17e6e5-fd03-a01b-9692-4dd9d7bffcb0@redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) Received-SPF: softfail client-ip=212.27.42.5; envelope-from=serge.guelton@telecom-bretagne.eu; helo=smtp5-g21.free.fr X-Spam_score_int: -9 X-Spam_score: -1.0 X-Spam_bar: - X-Spam_report: (-1.0 / 5.0 requ) BAYES_00=-1.9, HEADER_FROM_DIFFERENT_DOMAINS=0.249, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_NONE=0.001, SPF_SOFTFAIL=0.665, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: qemu-devel@nongnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Florian Weimer , Stefan Hajnoczi , Richard Henderson , qemu-devel , Stefan Hajnoczi Errors-To: qemu-devel-bounces+qemu-devel=archiver.kernel.org@nongnu.org Sender: "Qemu-devel" On Thu, Feb 17, 2022 at 12:40:40PM +0100, Paolo Bonzini wrote: > On 2/17/22 10:28, Stefan Hajnoczi wrote: > >>But going against ABI and toolchain in this way is really no long-term > >>solution. You need to switch to stackless co-routines, or we need to > >>provide proper ABI-level support for this. Today it's the thread > >>pointer, tomorrow it's the shadow stack pointer, and the day after that, > >>it's the SafeStack pointer. And further down the road, it's some thread > >>state for garbage collection support. Or something like that. > > > >Yes, understood :(. This does feel like solving an undefined behavior > >problem by adding more undefined behavior on top! > > Yes, this is the kind of thing that I generally despise when I see > other programs do it... it's easy to dig ourselves in the same > hole. > > >I took a quick look at C++20 coroutines since they are available in > >compilers but the primitives look hard to use even from C++, let alone > >from C. > > They're C++ only in GCC, too. I really think that QEMU should be > compilable in C++, but I'm not sure how easy a sell it is. It's perfectly fine to have one compilation unit written in C++ with a few symbol in `extern "C"`. No need to touch the other part of the project.