From patchwork Wed Mar 29 14:39:46 2023 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Nick Clifton X-Patchwork-Id: 76636 Return-Path: Delivered-To: ouuuleilei@gmail.com Received: by 2002:a59:b0ea:0:b0:3b6:4342:cba0 with SMTP id b10csp463211vqo; Wed, 29 Mar 2023 07:40:01 -0700 (PDT) X-Google-Smtp-Source: AKy350bW4IxTV0h3xPYqGLHj4CSNgxkEHyrtUAJ2ru0mjo4dD8NkBf7xoyUFkD39Bf7QCuUqbN5m X-Received: by 2002:a17:906:3f89:b0:877:a9d2:e5e9 with SMTP id b9-20020a1709063f8900b00877a9d2e5e9mr21707190ejj.42.1680100801124; Wed, 29 Mar 2023 07:40:01 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1680100801; cv=none; d=google.com; s=arc-20160816; b=fD7gXwhKkAUVy4ROweUoseRDCc1nMJSLVRx+esPAwyJd4W7zQVHvbiKyDGjnd2EycP mz/EpJ3lBGP2UvRACizyyajEG3BsYbnYP4i1kK4VtZ8mWa0bDnuLLjZSNfjoGIjbUPUP HZJ3nM8rnhM7bcMLQ8a7K9+MPZUmqFH6QR0Q95LzphrYKA+YWMNmRJr/5a1pO/8aGS8z 3eTkAEbm33Fl8WclLB7dIvuj/vEKv5Gaz6DbZmGDFx7qmlDwzmzHt0pnq+hZpWE11A+r FPSjjwbAJ4qUh+4eBU4HQMEJIxCFm/Y9077unObucvxijCkMqDnadHRNG8bGsCRw9PWH PH0Q== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=sender:errors-to:reply-to:from:list-subscribe:list-help:list-post :list-archive:list-unsubscribe:list-id:precedence:mime-version :message-id:date:cc:subject:to:dmarc-filter:delivered-to :dkim-signature:dkim-filter; bh=206MA8NH8SbfevPnIpsiNVg8opByIFptC4BIlX+b32M=; b=mNT/XDGzw2JIKIvM8yqSwefC9TMcmrLHFvcT4itlg5YMmXVbvm+I9VfhMTkBnTIqGn yha4fUgoCFG+0SaXB+jA7qCnALe9ElY1blCdp+eTyxTuw2biu2t07ETFCP2hK1TRzeUn +pfsF7MufI3zOBg1LuwSVU1TKK7EnuOUob/cLYSLx7HmWM0WqgWMDoCKeegAfdJGgx8Q KlGlX+wYCuYFy0WCj997Q38MLSIqD2XAm6emleb70W+n63ib3u3bbMYSPueimTqPz6sN QfihTog86TSEEFquLFMdNywSQ/eSlj7fSA8CUhPrCrJGzY2flRzePw2ljSUjs76MNbE2 HrWg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@sourceware.org header.s=default header.b=usC5vuZh; spf=pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="binutils-bounces+ouuuleilei=gmail.com@sourceware.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sourceware.org Received: from sourceware.org (server2.sourceware.org. [8.43.85.97]) by mx.google.com with ESMTPS id h8-20020a170906398800b00921792dda11si32646969eje.453.2023.03.29.07.40.00 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Mar 2023 07:40:01 -0700 (PDT) Received-SPF: pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 8.43.85.97 as permitted sender) client-ip=8.43.85.97; Authentication-Results: mx.google.com; dkim=pass header.i=@sourceware.org header.s=default header.b=usC5vuZh; spf=pass (google.com: domain of binutils-bounces+ouuuleilei=gmail.com@sourceware.org designates 8.43.85.97 as permitted sender) smtp.mailfrom="binutils-bounces+ouuuleilei=gmail.com@sourceware.org"; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=sourceware.org Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 67325385840F for ; Wed, 29 Mar 2023 14:39:59 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 67325385840F DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1680100799; bh=206MA8NH8SbfevPnIpsiNVg8opByIFptC4BIlX+b32M=; h=To:Subject:CC:Date:List-Id:List-Unsubscribe:List-Archive: List-Post:List-Help:List-Subscribe:From:Reply-To:From; b=usC5vuZhWUrT9zxStQ57uPcm9v4xoSa8z22mM65Z++rqNg926vAifkFoIg400kd8S POtonJUxwl8CnRTpavXK6tUeLNTenHMrIJBsW6DqNfxqngTCrrSIlYKKKUynQfHXe7 ahUsZjKVREm9Le+US7j5oE+j3ul7ZHtAuJxIcygY= X-Original-To: binutils@sourceware.org Delivered-To: binutils@sourceware.org Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 53FCE3858D1E for ; Wed, 29 Mar 2023 14:39:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 53FCE3858D1E Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-364-9jFe3u70NcOudd8RI9nXoA-1; Wed, 29 Mar 2023 10:39:49 -0400 X-MC-Unique: 9jFe3u70NcOudd8RI9nXoA-1 Received: from smtp.corp.redhat.com (int-mx08.intmail.prod.int.rdu2.redhat.com [10.11.54.8]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 630B7299E760; Wed, 29 Mar 2023 14:39:48 +0000 (UTC) Received: from prancer.redhat.com (unknown [10.33.36.5]) by smtp.corp.redhat.com (Postfix) with ESMTPS id ABE78C15BA0; Wed, 29 Mar 2023 14:39:47 +0000 (UTC) To: binutils@sourceware.org Subject: RFC: Can static executables contain relocations against symbols ? CC: mjw@fedoraproject.org, amulhern@redhat.com Date: Wed, 29 Mar 2023 15:39:46 +0100 Message-ID: <87v8ijmxjh.fsf@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.8 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com X-Spam-Status: No, score=-10.0 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H2, SPF_HELO_NONE, SPF_NONE, TXREP autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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-Patchwork-Original-From: Nick Clifton via Binutils From: Nick Clifton Reply-To: Nick Clifton Errors-To: binutils-bounces+ouuuleilei=gmail.com@sourceware.org Sender: "Binutils" X-getmail-retrieved-from-mailbox: =?utf-8?q?INBOX?= X-GMAIL-THRID: =?utf-8?q?1761713377937544109?= X-GMAIL-MSGID: =?utf-8?q?1761713377937544109?= Hi Guys, Can static executables contain relocations against symbols ? This question has come up in Fedora as part of the investigation into a problem linking some binaries compiled with the Rust compiler: https://bugzilla.redhat.com/show_bug.cgi?id=2166149 The issue appears to be that static-pie executables are being created with a .rela.got section that has an sh_link field set to point to the .symtab section. This in turns means that running strip on the executables will not remove the .symtab section, which is then being flagged as an error by the build system. The problem is not happening for x86_64 binaries because they contain a .dynsym section, and the code in bfd/elf.c:assign_section_numbers will preferentially use that section if it exists. (It is not clear to me *why* x86_64 static pie binaries contain a .dynsym section, but they do). It is possible for static executables to contain relocations - for ifuncs for example - but I think that they should always be absolute. So my question is: is it safe to set the sh_link field for relocation sections in static executables to 0 ? The attached patch is a suggestion for the change I am considering... Thoughts ? Cheers Nick diff --git a/bfd/elf.c b/bfd/elf.c index 45e53640e8f..0b5c8c79fd6 100644 --- a/bfd/elf.c +++ b/bfd/elf.c @@ -3884,7 +3884,25 @@ assign_section_numbers (bfd *abfd, struct bfd_link_info *link_info) d->this_hdr.sh_link = elf_section_data (s)->this_idx; } if (d->this_hdr.sh_link == 0) - d->this_hdr.sh_link = elf_onesymtab (abfd); + { + /* In general static executables should not need relocations. + There are exceptions however, for ifuncs for example, but + in these cases the relocations should not need any symbols. + Hence it should be safe to leave the sh_link field as 0. + Not setting sh_link allows the symbol table to be stripped + from the executable, which is a desirable trait. + + FIXME: Should we scan the relocations first to make sure + that there are no symbol references ? */ + if (link_info != NULL + && bfd_link_executable (link_info) + && (abfd->flags & DYNAMIC) == 0) + ; + else + d->this_hdr.sh_link = elf_onesymtab (abfd); + } s = elf_get_reloc_section (sec); if (s != NULL)