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 [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id A805A3839C48 for ; Thu, 8 Jul 2021 07:27:18 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A805A3839C48 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-370-uN9nPMWnOMO1aNinbsP8eA-1; Thu, 08 Jul 2021 03:27:16 -0400 X-MC-Unique: uN9nPMWnOMO1aNinbsP8eA-1 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx01.redhat.com (Postfix) with ESMTPS id CF19F5074E; Thu, 8 Jul 2021 07:27:15 +0000 (UTC) Received: from oldenburg.str.redhat.com (ovpn-115-5.ams2.redhat.com [10.36.115.5]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 6695A421F; Thu, 8 Jul 2021 07:27:14 +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> <87v95yxtp7.fsf@oldenburg.str.redhat.com> Date: Thu, 08 Jul 2021 09:27:12 +0200 In-Reply-To: (H. J. Lu's message of "Mon, 28 Jun 2021 04:55:19 -0700") Message-ID: <87zguxw9in.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.79 on 10.5.11.11 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain X-Spam-Status: No, score=-6.8 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_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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: Thu, 08 Jul 2021 07:27:19 -0000 * H. J. Lu: >> >> 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 > > That is correct. > >> impose anything on the rest of the link. I do not see the markup >> covering that. > > The absence of the marker tells ld.so that copy relocation against > protected symbols in the executable is incompatible with the shared > library with the protected symbol AND the marker. Maybe I don't completely understand the direction in which is is moving. Is the idea to phase out copy relocations in general? Or just disable them for protected symbols? Thanks, Florian