From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 1AE003858401 for ; Tue, 12 Mar 2024 13:47:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 1AE003858401 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 1AE003858401 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710251270; cv=none; b=o2ci/b4TJPp5e8aawGqMHBEAqvij2l6Q1DjLtE1WIkfu4T+b5fogcMbIyjcEkbM8fHCXJ12Yx2pny5kl1VTV34toch+Hd8/G1jUG2wShjTWDEkVhpguxFwPfvBuRJw9/38yjy92v3XgmcwGgRh5F6TTIrTK45ArnYrZwhdI9BSE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1710251270; c=relaxed/simple; bh=opKdebD8mmvHE6sRWztUM8gWRJp/mHJKfX6xcyJc8UQ=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=YtNFSPXm9spzdS6I3/7pkVlYKsvmRDS4H387xLhtI6jM5AplZL8fy8tA2XALoLTyD9FqH0S1vBdd0RVO4a0KoZRXBiG7k20syMFeE6BqWkSez+oj0cNdotfC0S4pM7IRqEaX86iDMzUcsiyFiNVN1/pwiCQ6FcTteWdt5/cCCBY= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1710251268; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: in-reply-to:in-reply-to:references:references; bh=mfHwimF193AXR9/Cf651JPpiVnElbMEZb9PimIErHNQ=; b=gcqJ3oq0nVstKhc6sUjukLhua36skHQhRMYSB25rHBso5X0UCI+R++yrW0Tm3eBpMS34E4 9q+BdpD/h8och61+y5HxZATjezJz7LOg9VEF5SAvaId5zmsc7xeRECpgbZeRJDv+fX8HOT 13aUYZ7zcGMEAf05mqkY5IkaO6ScemQ= Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-132-xAtD8nICOcysSKQBo3cByw-1; Tue, 12 Mar 2024 09:47:45 -0400 X-MC-Unique: xAtD8nICOcysSKQBo3cByw-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 31B301C382A1; Tue, 12 Mar 2024 13:47:45 +0000 (UTC) Received: from oldenburg.str.redhat.com (unknown [10.39.192.73]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 8F8C82166B4F; Tue, 12 Mar 2024 13:47:44 +0000 (UTC) From: Florian Weimer To: Andrew Pinski Cc: GNU C Library Subject: Re: swapcontext happening on different threads References: Date: Tue, 12 Mar 2024 14:47:42 +0100 In-Reply-To: (Andrew Pinski's message of "Tue, 12 Mar 2024 00:24:21 -0700") Message-ID: <87a5n3v9xd.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.3 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-5.2 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_SHORT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H4,RCVD_IN_MSPIKE_WL,SPF_HELO_NONE,SPF_NONE,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: * Andrew Pinski: > Reference https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65712 . > > I am not 100% sure if this is a valid thing to do. > But take the code in the referenced GCC bug report. Currently since > pthread_self is marked as const, if you swap to a different context > and then have that context be swapped on a different thread, you > might/will get the old value of pthread_self in some cases. > > Is this well defined or is this a corner case that was not expected. I > don't see anywhere in the older versions of POSIX that explain what > would happen if you do that. And glibc's documentation does not talk > about this case either. > > It would be useful if the documentation talked about this either way. There have been passed discussions about this on the gcc list, for other stackful coroutine implementations. QEMU in particular needs a way to implement a barrier for thread-local variable optimizations. This is not just about const functions like pthread_self or __errno_location, it impacts GCC code generation for TLS variable access as well. Disabling TLS address caching to help QEMU on GNU/Linux I'm sure the QEMU developers would still appreciate explict TLS address barriers in GCC. As part of this, maybe we can get a replacement function attribute to replace const for those functions. Thanks, Florian