From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on dcvr.yhbt.net X-Spam-Level: X-Spam-ASN: AS3215 2.6.0.0/16 X-Spam-Status: No, score=-4.2 required=3.0 tests=AWL,BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,SPF_HELO_PASS,SPF_PASS shortcircuit=no autolearn=ham autolearn_force=no version=3.4.2 Received: from sourceware.org (server2.sourceware.org [IPv6:2620:52:3:1:0:246e:9693:128c]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by dcvr.yhbt.net (Postfix) with ESMTPS id 39BDE1F8C6 for ; Tue, 22 Jun 2021 15:36:51 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6F6B1393AC0B for ; Tue, 22 Jun 2021 15:36:49 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6F6B1393AC0B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1624376209; bh=d3JWMqWKZuQU0rLl9AlW9+nugIHPWLrk34eQHf7jTMA=; h=To:Subject:References:Date:In-Reply-To:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=vzP+weS59yNWRiDm5T/M240HBtpxxBjS6Lj5/jMTdS6+NhiHDiKE1/mvGY6m//WDP U3/PlcTRxGOUmzR5K7qt8YSiEd5pwB5HMo+BWYYvDXVJvozGCINzByc9g98mftGwfL hKolXgN0zOAKoqYuaeCc5m9C4Iy4MxKXGpz0NuEs= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [216.205.24.124]) by sourceware.org (Postfix) with ESMTP id A81593857001 for ; Tue, 22 Jun 2021 15:36:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A81593857001 Received: from mimecast-mx01.redhat.com (mimecast-mx01.redhat.com [209.132.183.4]) (Using TLS) by relay.mimecast.com with ESMTP id us-mta-501-sIL42pjROTGyGTeE6SlMPg-1; Tue, 22 Jun 2021 11:36:25 -0400 X-MC-Unique: sIL42pjROTGyGTeE6SlMPg-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.phx2.redhat.com [10.5.11.16]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 6A2F5804141; Tue, 22 Jun 2021 15:36:24 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-112-211.ams2.redhat.com [10.36.112.211]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 7EEC45C1D1; Tue, 22 Jun 2021 15:36:22 +0000 (UTC) To: John Mellor-Crummey Subject: Re: A collection of LD_AUDIT bugs that are important for tools (with better formatting for this list) References: <8A8FF420-8316-4A22-AC4D-DA1F2D5625A5@rice.edu> <2fc830b9-35da-9b94-369f-4df683078a5c@linaro.org> <8735tguubc.fsf@oldenburg.str.redhat.com> <5F849F6D-0BB7-4D6F-9FC8-9F73A4E012F3@rice.edu> <87tulqe2mc.fsf@oldenburg.str.redhat.com> <96DC1048-EA3C-4DF5-BF16-A567F7C56BDE@rice.edu> Date: Tue, 22 Jun 2021 17:36:20 +0200 In-Reply-To: <96DC1048-EA3C-4DF5-BF16-A567F7C56BDE@rice.edu> (John Mellor-Crummey's message of "Tue, 22 Jun 2021 10:04:43 -0500") Message-ID: <87o8bxdi8b.fsf@oldenburg.str.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.2 (gnu/linux) MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.79 on 10.5.11.16 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-BeenThere: libc-alpha@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Libc-alpha mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Florian Weimer via Libc-alpha Reply-To: Florian Weimer Cc: libc-alpha@sourceware.org, Xiaozhu Meng , "Mark W. Krentel" Errors-To: libc-alpha-bounces+e=80x24.org@sourceware.org Sender: "Libc-alpha" * John Mellor-Crummey: >> On Jun 22, 2021, at 3:15 AM, Florian Weimer wrote: >> You can already see this non-interceptable thread creation behavior >> today (in glibc 2.33 and earlier) with thrd_create, which does not >> result in a pthread_create call, either, despite creating a new thread >> as if by pthread_create. > > Having a non-interposable thrd_create is a problem for us too, though=20 > we haven=E2=80=99t yet seen it in practice in HPC applications (or maybe = it happened > and we were just unaware!). I meant that thrd_create needs to be intercepted separately. This will still work. >> Going back to trheading, I find it a bit curious that you intercept >> pthread_create, but not pthread_join. How do you detect thread exit? I >> assume you are interested in that event, too. Merely wrapping the >> thread start routine is insufficient because there are other ways for a >> thread to exit besides returning from the start routine and calling >> pthread_exit (e.g., thread cancellation and unwinding). > > We use pthread_cleanup_push to add a routine that will be called when a t= hread > exits. Okay, that should work, although some application-supplied TLS destructors will run later than that. Thanks, Florian