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=-3.5 required=3.0 tests=AWL,BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS,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 080341F5AE for ; Wed, 28 Apr 2021 13:15:14 +0000 (UTC) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id E247B3A71C2C; Wed, 28 Apr 2021 13:15:12 +0000 (GMT) Received: from mx2.suse.de (mx2.suse.de [195.135.220.15]) by sourceware.org (Postfix) with ESMTPS id DD8B0385701E; Wed, 28 Apr 2021 13:15:10 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org DD8B0385701E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=suse.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=matz@suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.221.27]) by mx2.suse.de (Postfix) with ESMTP id F41ACB180; Wed, 28 Apr 2021 13:15:09 +0000 (UTC) Date: Wed, 28 Apr 2021 13:15:09 +0000 (UTC) From: Michael Matz To: Florian Weimer Subject: Re: Undefined use of weak symbols in gnulib In-Reply-To: <87h7jqkdrn.fsf@oldenburg.str.redhat.com> Message-ID: References: <87o8e0p92r.fsf@oldenburg.str.redhat.com> <87fszc8a1z.fsf@igel.home> <87eeewnfzw.fsf@oldenburg.str.redhat.com> <1680226.UWtE2gOZdF@omega> <87h7jqkdrn.fsf@oldenburg.str.redhat.com> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 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 , bug-gnulib@gnu.org, "H.J. Lu via Libc-alpha" , Bruno Haible , Binutils Errors-To: libc-alpha-bounces@sourceware.org Sender: "Libc-alpha" Hello, On Wed, 28 Apr 2021, Florian Weimer via Binutils wrote: > > commit 954b63d4c8645f86e40c7ef6c6d60acd2bf019de > > Author: Alan Modra > > Date: Wed Apr 19 01:26:57 2017 +0930 > > > > Implement -z dynamic-undefined-weak > > > > -z nodynamic-undefined-weak is only implemented for x86. (The sparc > > backend has some support code but doesn't enable the option by > > including ld/emulparams/dynamic_undefined_weak.sh, and since the > > support looks like it may be broken I haven't enabled it.) This patch > > adds the complementary -z dynamic-undefined-weak, extends both options > > to affect building of shared libraries as well as executables, and > > adds support for the option on powerpc. > > I'm not sure if this option is compatible with all compilers on POWER. > > The old binutils behavior allowed the compiler to optimize this common > pattern > > void f1 (void) __attribute__ ((weak)); > > void > f2 (void) > { > if (f1 != 0) > f1 (); > } > > into an unconditional call to f1 because the linker would replace the > call with a NOP if the symbol is undefined, reproducing the effect of > the if condition. However, GCC 10 does not appear to perform this > optimization on powerpc64le. GCC assumes addresses of functions to be non-null, _except when declared weak_. Over the years we fixed problem in that aspect always into that direction (hence the above testcase should always be emitted with an actual test, otherwise it would be considered a bug worth fixing). That would be consistent with making undefined weak symbols dynamic in the ELF case, so that the ultimate test survives until runtime. I don't know what other compilers are doing, of course. Ciao, Michael.