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: AS17314 8.43.84.0/22 X-Spam-Status: No, score=-3.8 required=3.0 tests=AWL,BAYES_00,DKIM_INVALID, DKIM_SIGNED,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI, NICE_REPLY_A,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 [8.43.85.97]) (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 851FD1F5AE for ; Wed, 28 Apr 2021 14:48:41 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id D2F9F3AA142A; Wed, 28 Apr 2021 14:48:28 +0000 (GMT) Received: from mo4-p01-ob.smtp.rzone.de (mo4-p01-ob.smtp.rzone.de [85.215.255.52]) by sourceware.org (Postfix) with ESMTPS id D68903AA006C; Wed, 28 Apr 2021 14:48:23 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org D68903AA006C Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=clisp.org Authentication-Results: sourceware.org; spf=none smtp.mailfrom=bruno@clisp.org ARC-Seal: i=1; a=rsa-sha256; t=1619621302; cv=none; d=strato.com; s=strato-dkim-0002; b=SLYCwHbgONFwPNFcUDtEsN5ntuykOu8rWDVT97LuVzFxzXnPFgcryi+KHydKYjHOka CFvpCA/7btgoMgvZwioQqFzv+gBlTGnEHI3RYlSPolF6wVZlgLOvqSFSN4Fy8l2j2ulD +BAvVAdnBGwfOn/ba9iIVJ3Yrr9TLT0Wjq/Hh6Jq6e/wN4X7vZvN/Dx2UqGObkGzabLj b609objV4bxa0O7egPPzX5k1CDnyr/0yG46Gm1abQ2wTAw0tEIizlJ5q3IeqE5JbZmj/ ilLpLk9Vc2cUVDOsmEvHJwEesnZghLK+1nCMJ2VObY3gVagn7kzJRDm6cuSBhgaZ3DIR TxMA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; t=1619621302; s=strato-dkim-0002; d=strato.com; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=rsvty3vTWFDov0s0FeTbIdVgXw+aNqf/4l25/B+Yzfw=; b=I9jHrA1uBGaK8b5URXeW/q9UUsJhEX221NVVwIjXGG3SjftUCKRflAqYr/pfGBt3AM Gd4wHZ1wUG5/zWuu5O7RkwUrMEK5FfmwRYyFg51UU7lRf9nN4noawzcKy3Ir0nC63zgA 7NKLlco2/9D//wZJVPN8o9Yd5/VnesmT0x/b+KEIm8CAsBKeWCKCOl4F/EOnB84xk35n TX125or1JMzOwzQ9uMuHt4iwRiPdEOfnqnrQzzaBWqDmPhYwKzJFcOvTlpbkdHUHHTJB NeMCfyXOafbLMMu+OwSlrhXt5JS7Ct1K0QO3TdX5elXV+MICJNHucyArOVZAiH+ZrPgM sMQg== ARC-Authentication-Results: i=1; strato.com; dkim=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1619621302; s=strato-dkim-0002; d=clisp.org; h=References:In-Reply-To:Message-ID:Date:Subject:Cc:To:From:Cc:Date: From:Subject:Sender; bh=rsvty3vTWFDov0s0FeTbIdVgXw+aNqf/4l25/B+Yzfw=; b=X/Ebl2fyWXsN6/O93cAsBRWQdZNumbzCOPkq+JncIvcXg0zJH+Wpb8/Zsb6huZAtfa EGusYthyQ4mLF5HCotdtJ0bXkWQtz0TtNdCNeWsCYcWwTK/+8k84/ModYEFVG/I4zgLG VaTQoTk2/bqEgOSo2ZiMDy2m3zEFyxfqyMrdcs9nf6OqbyHE+FtdGrvp0hokLaYVJQOv RCQXLqV3jKS29gy668vni76Gy8RZGbS6eKq9f4tTQOs8GQrx4kCCibMtWyrvYb/Whe8+ Q4Utm1CPuxAxtJJe8rKd4qfvnik9hT3JyHABrbQmQbCLqGCJOFCJSx1SWoUeZ+asFIcq 21nw== Authentication-Results: strato.com; dkim=none X-RZG-AUTH: ":Ln4Re0+Ic/6oZXR1YgKryK8brlshOcZlIWs+iCP5vnk6shH+AHjwLuWOHqf3z5NW" X-RZG-CLASS-ID: mo00 Received: from bruno.haible.de by smtp.strato.de (RZmta 47.25.2 DYNA|AUTH) with ESMTPSA id 905ad3x3SEmL8ND (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (curve X9_62_prime256v1 with 256 ECDH bits, eq. 3072 bits RSA)) (Client did not present a certificate); Wed, 28 Apr 2021 16:48:21 +0200 (CEST) From: Bruno Haible To: Florian Weimer Subject: Re: Undefined use of weak symbols in gnulib Date: Wed, 28 Apr 2021 16:48:20 +0200 Message-ID: <3309003.lbPZiPdySv@omega> User-Agent: KMail/5.1.3 (Linux/4.4.0-206-generic; KDE/5.18.0; x86_64; ; ) In-Reply-To: <87a6piluow.fsf@oldenburg.str.redhat.com> References: <87o8e0p92r.fsf@oldenburg.str.redhat.com> <1680226.UWtE2gOZdF@omega> <87a6piluow.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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: , Cc: Andreas Schwab , libc-alpha@sourceware.org, bug-gnulib@gnu.org, binutils@sourceware.org Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" Florian Weimer wrote: > > $ gcc -Wall -fpie -pie foo.c ; ./a.out > > initialization code > > > > $ gcc -Wall -fpie -pie foo.c -Wl,--no-as-needed -lpthread ; ./a.out > > multi-threaded initialization > > initialization code > > > > What will change for this program with glibc 2.34? > > If recompiled in this way: The presence of -lpthread will not matter, it > will always behave is if linked with -lpthread. So it will print multi-threaded initialization initialization code in all cases. This is perfectly fine. > The relevant scenario here is LD_PRELOAD of a library that depends on > libpthread.so.0 ... > If not recompiled and linked without -lpthread against glibc 2.33 or > earlier, the behavior with the current glibc 2.34 snapshot is > architecture-dependent and also depends on the binutils version used for > linking the program. In some cases, calling pthread_once jumps to > address zero (causing a crash), or the call to pthread_once is elided > from the executable. This scenario can be emulated with older glibc > using LD_PRELOAD=libpthread.so.0. I'm confused again. Are you saying that the crash will occur when old binaries are being used with glibc 2.34 also *without* LD_PRELOAD? Bruno