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 340303858C54 for ; Thu, 11 May 2023 18:12:19 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 340303858C54 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1683828738; 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=EzMPVFkxF0bgQCiG5ie5nCOFdWM1iZMInpKHbo21q8g=; b=JD5fYB4Wwq5hjP/n26ER4ZJZR4tl6f4O/UeeOdL0fWdrRUx/Oe+1NwwCCtfKsQCTcFGtgf 4uNpoCYhFlpaRCEEvBSw/PKmVDDGBGRVQRojpf6gibcNh34eB6RjXaDWqY7LVmszoVtBIY xqXGLdLVlQ+wCG2N5EfEcwMrppEQ0K4= Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-66-kqBHSP7PM5avUd94LWpG4Q-1; Thu, 11 May 2023 14:12:14 -0400 X-MC-Unique: kqBHSP7PM5avUd94LWpG4Q-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.rdu2.redhat.com [10.11.54.1]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 4DE521C12F80; Thu, 11 May 2023 18:12:14 +0000 (UTC) Received: from oldenburg3.str.redhat.com (unknown [10.39.195.72]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 5746540C2076; Thu, 11 May 2023 18:12:13 +0000 (UTC) From: Florian Weimer To: Sergey Bugaev Cc: libc-alpha@sourceware.org, bug-hurd , Samuel Thibault Subject: Re: __pthread_setcancelstate called unconditionally, crashes at 0 References: <87ilcyg3ud.fsf@oldenburg3.str.redhat.com> Date: Thu, 11 May 2023 20:12:12 +0200 In-Reply-To: (Sergey Bugaev's message of "Thu, 11 May 2023 21:00:14 +0300") Message-ID: <874joig2kj.fsf@oldenburg3.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.1 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-4.5 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,KAM_NUMSUBJECT,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_NONE,TXREP,T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: * Sergey Bugaev: >> If you need async cancellation support, the core cancellation routine >> could be made weak, so that it is linked into the executable only if >> pthread_cancel is ever called. > > Could you please expand on how this all (unwinding, async > cancellation) is relevant? Clearly calling error () in a > PTHREAD_CANCEL_ASYNCHRONOUS context is undefined behavior since error > () is not async-cancel-safe. I'd expect __pthread_setcancelstate to act on asynchronous cancellation if it is enabled. Once you implement that and have a strong symbol reference to __pthread_setcancelstate, you'd pull in the cancellation unwinder without additional measures, and this would into every program. You probably don't want that. So the reference to the core cancellation had better be weak (or use the __libc_ptf_call indirection). Does this answer your question? Sorry, these static linking size optimizations are tricky. Thanks, Florian