From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 A1928394FC00 for ; Mon, 28 Jun 2021 08:46:35 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A1928394FC00 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-261-L_04nIOFN2mJlRUHTQ4enQ-1; Mon, 28 Jun 2021 04:46:33 -0400 X-MC-Unique: L_04nIOFN2mJlRUHTQ4enQ-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.phx2.redhat.com [10.5.11.23]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id 92464804142; Mon, 28 Jun 2021 08:46:31 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-112-228.ams2.redhat.com [10.36.112.228]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 25BBA453B; Mon, 28 Jun 2021 08:46:29 +0000 (UTC) From: Florian Weimer To: "H.J. Lu" Cc: Binutils , Alan Modra , Nick Clifton , Richard Earnshaw Subject: Re: [PATCH v3 2/2] elf: Add GNU_PROPERTY_1_NEEDED check References: <20210624132411.1993105-1-hjl.tools@gmail.com> <20210624132411.1993105-3-hjl.tools@gmail.com> <87o8bu826v.fsf@oldenburg.str.redhat.com> Date: Mon, 28 Jun 2021 10:46:28 +0200 In-Reply-To: (H. J. Lu's message of "Fri, 25 Jun 2021 11:52:31 -0700") Message-ID: <87v95yxtp7.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.84 on 10.5.11.23 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.7 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_LOW, RCVD_IN_MSPIKE_H4, RCVD_IN_MSPIKE_WL, 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: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 28 Jun 2021 08:46:37 -0000 * H. J. Lu: >> Should the property be used just for error checking? We would flip the >> default unconditionally. Such a behavioral change simply based on some >> input file is quite surprising. > > The property is used to to allow compiling sources with > -fno-direct-extern-access > by pieces. When creating a shared library, if one input relocatable file > is compiled with -fno-direct-extern-access, linker will bind all protected > symbols locally before seeing ALL relocations against them in different > input relocatables files. What is the advantage of this behavior? Why should the presence of one such object file in the link cause symbol binding behavior change everywhere? Especially if that one file does not even reference any protected symbols? >> For (4), I think we need to set a different flag (or perhaps even >> flags), and be really careful about what we do. I think an output file >> that is an executable will never require indirect-extern-access, but it > > What did you mean by that? We need to compile executable with > -fno-direct-extern-access for the whole scheme to work. indirect-extern-access imposes a requirement on executables, but building an executable to comply with the new requirements will not impose anything on the rest of the link. I do not see the markup covering that. >> can be incompatible with indirect-extern-access objects at run time. >> Shared objects as output files may themselves depend on >> indirect-extern-access objects at run time. Ideally, markup would be >> applied to the relocations that are affected by the changes in the ABI. > > That is what my glibc changes do: > > $ ./elf/tst-protected1a > ./elf/tst-protected1a: protected1: > /export/build/gnu/tools-build/glibc-gitlab/build-x86_64-linux/elf/tst-protected1moda.so: > copy relocation against non-copyable protected symbol > $ readelf -r ./elf/tst-protected1a | grep COPY > 0000004071d8 004300000005 R_X86_64_COPY 00000000004071d8 protected1 + 0 > 0000004071dc 004600000005 R_X86_64_COPY 00000000004071dc protected3 + 0 > > This error happens only if there is a copy relocation against protected symbol > definition compiled with -fno-direct-extern-access. Does this mean that executables do not need any markup at all, and that looking at the relocation types is sufficient? (Same for canonical function addresses.) Thanks, Florian