From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pf1-x42f.google.com (mail-pf1-x42f.google.com [IPv6:2607:f8b0:4864:20::42f]) by sourceware.org (Postfix) with ESMTPS id 410E43857C7F; Mon, 3 May 2021 01:45:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 410E43857C7F Received: by mail-pf1-x42f.google.com with SMTP id c17so3106515pfn.6; Sun, 02 May 2021 18:45:01 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=ML9XLCyjbckcSiZbJM80DFQO0Of7S3z58gr+cmuUCqc=; b=VpLrE51HPQbkRjjUMgCuWtLesZiKuc1Z6R7Puzkwx+XbDi1VucFvHJot7aTSQFQ1Ky 5IZ3k6qX1aDLEZTSRh2sAeqWrZ9oH4bD9tofoczZXeivSje8Ik/COeKnpguT2GjeLt0D N7LZXXeUVhUnUlKr4LEkSqPTkq2qRq3sEW8yO4QtObz0rWEXlCLPsdjlsX0drxzb/sIu loOKmIXiy1lmKkhwDvDpbEhC8I941+AuxL3ofy2KJGPtAu56b0iRVySbaeBoiuq/SUJE 1GRqlb7iaiOJd1eWzU9QurbQEUTGNiVnJ2i9S08YPQhFvsG8w9XRqq4esDO41FGuUrfp AmBw== X-Gm-Message-State: AOAM533+x//fC1Qm+SK0m2gBNXuRyZ5HXMTq2Z2lA4V7COSpi+lY+t5t POFbxYxYMwdmPw3Jd2xMic4= X-Google-Smtp-Source: ABdhPJyOlzBl129hTapFlRvsNw6W0W8pUZ0v4E8GqUqQwg9NfCzQQrFhF5nRIFQv943OapCQ8AlBEw== X-Received: by 2002:a63:5801:: with SMTP id m1mr15831625pgb.424.1620006299449; Sun, 02 May 2021 18:44:59 -0700 (PDT) Received: from bubble.grove.modra.org (158.106.96.58.static.exetel.com.au. [58.96.106.158]) by smtp.gmail.com with ESMTPSA id h1sm7445891pfh.72.2021.05.02.18.44.58 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 02 May 2021 18:44:58 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id A6C0241B0A; Mon, 3 May 2021 11:14:54 +0930 (ACST) Date: Mon, 3 May 2021 11:14:54 +0930 From: Alan Modra To: Florian Weimer Cc: bug-gnulib@gnu.org, libc-alpha@sourceware.org, binutils@sourceware.org Subject: Re: Undefined use of weak symbols in gnulib Message-ID: <20210503014454.GA5774@bubble.grove.modra.org> References: <87o8e0p92r.fsf@oldenburg.str.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87o8e0p92r.fsf@oldenburg.str.redhat.com> User-Agent: Mutt/1.9.4 (2018-02-28) X-Spam-Status: No, score=-3034.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org 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: , X-List-Received-Date: Mon, 03 May 2021 01:45:02 -0000 On Tue, Apr 27, 2021 at 07:53:16AM +0200, Florian Weimer via Binutils wrote: > So the net effect is this: > > if (pthread_mutexattr_gettype != NULL) > pthread_once (control, callback); > > Dynamic linking with weak symbols is not very well-defined. On x86-64, > the link editor produces the expected dynamic symbol relocation for the > pthread_once call. On other targets (notably POWER), no dynamic > relocation is produced, and the code will crash if > pthread_mutexattr_gettype is ever defined. Yes, this construct is not handled in ppc32 and ppc64 ld. It also doesn't work with some combination of compiler flags on x86. Don't allow yourself to be fooled by only testing with compilers that default to -fpie.. For example, this on x86_64 with gcc-11 (and previous versions). $ cat ~/src/tmp/weakfunc2.c extern void func1 (void) __attribute__((weak)); extern void func2 (void) __attribute__((weak)); int main (void) { if (func1) func2 (); return 0; } $ gcc -O2 -c -fno-pie ~/src/tmp/weakfunc2.c $ gas/as-new -o empty.o /dev/null $ ld/ld-new -shared -o empty.so empty.o $ ld/ld-new -o weakfunc2 weakfunc2.o empty.so ld/ld-new: warning: cannot find entry symbol _start; defaulting to 0000000000401020 $ binutils/nm-new --dynamic weakfunc2 w func2 So func1 is resolved to zero at link time. Well, I guess that isn't unexpected. powerpc-linux and powerpc64-linux (both ABIs) have further problems that I'll fix. In particular the above testcase ought to work even though it looks wrong to test func1 non-NULL and then call func2. Slightly less weird is if (func1) { func1 (); func2 (); } which might be reasonable user code when it is known that func1 and func2 both exist or are both NULL. ppc gets that one wrong too. -- Alan Modra Australia Development Lab, IBM