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 ESMTPS id 53FCE3858D1E for ; Wed, 29 Mar 2023 14:39:51 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 53FCE3858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1680100791; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type; bh=206MA8NH8SbfevPnIpsiNVg8opByIFptC4BIlX+b32M=; b=WyodqwGilOFh+zsIUa71kFotWAyFzoeLGO1w8a/efxvUIoDxqDWoFHe9BzxUjALbRDTGCi 8z1DGaR0msaAi4RE5XD3pVkkGv2/nUPxUfS9dkljLY12JSbkUMJ4WeNBjw+/uWGx/hI3Je Z1UJ2i+8UDA4Zu9tX39P17TLpu5K8rA= 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) From: Nick Clifton 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 Content-Type: text/plain 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 List-Id: 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)