From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id A65093858D1E for ; Wed, 29 Mar 2023 15:47:04 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org A65093858D1E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: from r6.localdomain (82-217-174-174.cable.dynamic.v4.ziggo.nl [82.217.174.174]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 5146B313ACB4; Wed, 29 Mar 2023 17:47:03 +0200 (CEST) Received: by r6.localdomain (Postfix, from userid 1000) id 875373401CE; Wed, 29 Mar 2023 17:47:02 +0200 (CEST) Message-ID: <11c2f379ec297bc8368e5381b044e983008161ed.camel@klomp.org> Subject: Re: RFC: Can static executables contain relocations against symbols ? From: Mark Wielaard To: Nick Clifton , binutils@sourceware.org Cc: amulhern@redhat.com Date: Wed, 29 Mar 2023 17:47:02 +0200 In-Reply-To: <87v8ijmxjh.fsf@redhat.com> References: <87v8ijmxjh.fsf@redhat.com> Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable User-Agent: Evolution 3.46.4 (3.46.4-1.fc37) MIME-Version: 1.0 X-Spam-Status: No, score=-3029.1 required=5.0 tests=BAYES_00,JMQ_SPF_NEUTRAL,KAM_DMARC_STATUS,RCVD_IN_BARRACUDACENTRAL,SPF_HELO_NONE,SPF_PASS,TXREP 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: Hi Nick, On Wed, 2023-03-29 at 15:39 +0100, Nick Clifton wrote: > Can static executables contain relocations against symbols ? I see nothing in the standard that says they cannot, but also nothing that says that if there are no relocations against symbols (which is the case in the issue below) that a relocation section is required to point to a symbol table. > This question has come up in Fedora as part of the investigation into > a problem linking some binaries compiled with the Rust compiler: >=20 > https://bugzilla.redhat.com/show_bug.cgi?id=3D2166149 >=20 > 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. >=20 > 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). Note that the x86_64 .dynsym table actually is empty (contains a single null symbol). I think it makes sense that if you refer from an allocated relocation section to reference an allocated .dynsym section (even if it is empty) instead of referencing an unallocated .symtab section (because that won't be available at runtime). > 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 ? I think it is safe if you make sure there are no symbol references. Otherwise it seems it must point to an allocated .dynsym section and not an unallocated .symtab section. Cheers, Mark