From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-qk1-x72f.google.com (mail-qk1-x72f.google.com [IPv6:2607:f8b0:4864:20::72f]) by sourceware.org (Postfix) with ESMTPS id 5633E385C335 for ; Wed, 24 Aug 2022 14:37:29 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 5633E385C335 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-qk1-x72f.google.com with SMTP id h27so12782523qkk.9 for ; Wed, 24 Aug 2022 07:37:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc; bh=gDks/vZuzlt3MuW9aEI6xOjJVbfHHGjVigXYoc1Td2s=; b=gpYOFZyCDnyy4iRg34NU79jGwvCAqIGMRxcZpIVbrDSJSRNWuiUn+UuomstTBOK8Mc Nya9RcA5ABO2syoKbhiq9RhlFAFxpOoOo6MOJs+lMHiEQ8FHnBi1yGg9Ch+kyy8M3JXl hizePFDBltprdGSWn19/0ff6TvGe/5vPMGA9zn3NNIyJrn7UVXYNwE/PlBZicAyjuzUE HA1g2AxRtQRWtKVOA67bVrczzglYZgpq64mKDdjYtF0DWKiwo6s/MDV0gJTdOcGop5UV OlV5x1dvpW1NhB38i8VDGnYc4SkJM/gA3gE1x6mbQV26SeNRA9YTvUR/7DCMbZRbGIbq qe9Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc; bh=gDks/vZuzlt3MuW9aEI6xOjJVbfHHGjVigXYoc1Td2s=; b=SKeX8xvrQaKDTkpPjmQKKTMiWvdlIQPAk3XyYnqTRhYkwQFlavXJ5R0DEQBJQx6oki ZMHDzMNaind2Rh5Zgywvz9ZhtaW5A81AnHxUOt9kqV+u/iY7RwZb6pr8/qxflbtVf4mJ 9YCPvI/B6/FkVTiqA3YsEPrVylgMeq6h9JgKPmF5Oh3hJtyYJGw6WkbqSNdiTbcYrjK1 kt1sSxr0zOGZG3UUs8HUSuwYDRrCnNH+BTZX9JNZDQGGfcjMTohOPthVV56BbBfsP8xE ieO8G8hBfAK1gXS2eliMiRIknyQf7OefzRdaJkRxx+WaYLKkMsKzSYkEjP2SLT2yDdp9 veBg== X-Gm-Message-State: ACgBeo3DkpORIhArDkMiXZginemX6gUz/IQSAergs+hjEiqEBkCEjQdo /GfQnWdumVHJqx+wmqfmUZtKP1HLsLu9Hy1uWZk= X-Google-Smtp-Source: AA6agR4l9RU7r9Eb1SR1NyjrYFTq+RuO7l4anrLeOWqEWuTt7sxgTDDdamI8u6e9iXryQ+UujdeKuK6Q6birUJk5ilU= X-Received: by 2002:a05:620a:254d:b0:6ab:84b8:25eb with SMTP id s13-20020a05620a254d00b006ab84b825ebmr19688440qko.383.1661351848636; Wed, 24 Aug 2022 07:37:28 -0700 (PDT) MIME-Version: 1.0 References: <20220823173432.36035-1-hjl.tools@gmail.com> In-Reply-To: From: "H.J. Lu" Date: Wed, 24 Aug 2022 07:36:52 -0700 Message-ID: Subject: Re: [PATCH] x86: Ignore protected visibility in shared libraries on Solaris To: Alan Modra Cc: Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-3017.8 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,T_SCC_BODY_TEXT_LINE,URIBL_BLACK 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: On Tue, Aug 23, 2022 at 6:41 PM Alan Modra wrote: > > On Wed, Aug 24, 2022 at 09:46:32AM +0930, Alan Modra wrote: > > On Tue, Aug 23, 2022 at 10:34:32AM -0700, H.J. Lu via Binutils wrote: > > > On x86, the PLT entry in executable may be used as function address for > > > functions in shared libraries. If functions are protected, the function > > > address used in executable can be different from the function address > > > used in shared library. This will lead to incorrect run-time behavior > > > if function pointer equality is needed. By default, x86 linker issues > > > an error in this case. > > > > > > On Solaris, linker issued an error for > > > > > > struct tm *tb = (kind == CPP_time_kind::FIXED ? gmtime : localtime) (&tt); > > > > > > where gmtime is a protected function in libc.so. Use gmtime's PLT entry > > > in executable as function address is safe since function pointer equality > > > isn't needed. > > > > I'm curious as to how pointer_equality_needed came to be set for > > gmtime. > > Hmm, I figure it was -fno-PIC code with a R_X86_64_32 or R_X86_64_64 > referencing gmtime. And yes, -fno-PIC -mcmodel=medium will generate > R_X86_64_32 in a testcase like > > extern int f1 (int); > extern int f2 (int); > int foo (int what, int val) { return (what ? f1 : f2) (val); } > > So why exclude R_X86_64_32 with an ABI_64_P test before setting > func_pointer_ref in elf_x86_64_scan_relocs? The whole condition is /* At run-time, R_X86_64_64 can be resolved for both x86-64 and x32. But R_X86_64_32 and R_X86_64_32S can only be resolved for x32. Function pointer reference doesn't need PLT for pointer equality. */ if ((sec->flags & SEC_READONLY) == 0 && (r_type == R_X86_64_64 || (!ABI_64_P (abfd) && (r_type == R_X86_64_32 || r_type == R_X86_64_32S)))) func_pointer_ref = true; This is for relocations in data section (not readonly). The function pointer reference must use R_X86_64_64 if ABI_64_P is true. -- H.J.