From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pj1-x102b.google.com (mail-pj1-x102b.google.com [IPv6:2607:f8b0:4864:20::102b]) by sourceware.org (Postfix) with ESMTPS id 9D8B43858CDA for ; Thu, 30 Mar 2023 01:22:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 9D8B43858CDA Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pj1-x102b.google.com with SMTP id h12-20020a17090aea8c00b0023d1311fab3so18057352pjz.1 for ; Wed, 29 Mar 2023 18:22:07 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; t=1680139326; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:from:to:cc:subject:date:message-id:reply-to; bh=ksheVejdSKCJ55FQh33v9hx6yLPzJ7tdRHw8TULjLOQ=; b=T3T3mNaroJ886Fr7S3Ilq30DjFK6UPg56rZyMPiFlSBHdBIIWrDVHQTWLMZYnsF9GG At08iejm67+plmCxcGpEXrEzIedzmMmqDok3aGcdd/7sJBeLS6Zy9fbt9aC5eZQXtj/m Bu9Y7FOSMKeJm+hrpI+V+4dBIz+fVxC4usctneFAf24c9wPy05BDe5/+E4/ub4hvEOiQ l3XRfMcAfcqQ/8OtlUdYJM6MWwYX9YwbWUHdklyFFYYjI6KQ//kC1V9vEmkWpLKftmRj hYPuPP6EXijisI8NpT8iatnpNUOxlgjfEOqvsU0tipW4Szj2gBdoWKP6Gz1obvGP2qQ5 B3cQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1680139326; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=ksheVejdSKCJ55FQh33v9hx6yLPzJ7tdRHw8TULjLOQ=; b=XIC0Jvi7UTeSda7FbRk9UuYyfk86E/o4RjdZ5+lowwDLfL/LJFh6FggOs+3OSodxcP jVdsGqfNn0FuTFEvLvp7XzqGJ0q3DPwe4Vp7RyoiUlNi2r7OD45bPn+eizsHOKp5sHyM DxGUU1A0z6+JwYiIIKa+5PmC/JRzD3K8pe6xhKfUXFqW/x47FlxVX/qe2KRHX4a0DIeL N8kplnxJnUVXmEsbQg2H2N2K1gSifrqeXtKWjZuglLh3+yL1EphgO9Mve6XgK5OQ6XRT gSTokbTHLFDfZQ3D1qdfgKM8KZeJ3iYgsERrdOmipsGz31BT5XJs15sGbEmoRGVAz6cX eZqQ== X-Gm-Message-State: AO0yUKUUcTEk94Ok8JzTjkTBp+/JgYb0zMjfca2xFuHnpUeneYynkgPD zuyrgws1x3h1r5tJ643Iu+w= X-Google-Smtp-Source: AKy350aFP4NFiWE2mWNoJ8hIGSx2vPapHUjhY+j9b7khS8gYrvAP4ZcAdOz1+aPlFAKAfqRzcJEpog== X-Received: by 2002:a17:90a:53:b0:237:d2d8:3264 with SMTP id 19-20020a17090a005300b00237d2d83264mr22588496pjb.40.1680139326362; Wed, 29 Mar 2023 18:22:06 -0700 (PDT) Received: from squeak.grove.modra.org (158.106.96.58.static.exetel.com.au. [58.96.106.158]) by smtp.gmail.com with ESMTPSA id z12-20020a17090a1fcc00b0023b15e61f07sm2035995pjz.12.2023.03.29.18.22.05 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 29 Mar 2023 18:22:05 -0700 (PDT) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id 821661140588; Thu, 30 Mar 2023 11:52:01 +1030 (ACDT) Date: Thu, 30 Mar 2023 11:52:01 +1030 From: Alan Modra To: Nick Clifton Cc: binutils@sourceware.org, mjw@fedoraproject.org, amulhern@redhat.com Subject: Re: RFC: Can static executables contain relocations against symbols ? Message-ID: References: <87v8ijmxjh.fsf@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87v8ijmxjh.fsf@redhat.com> X-Spam-Status: No, score=-3035.1 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,GIT_PATCH_0,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,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: On Wed, Mar 29, 2023 at 03:39:46PM +0100, Nick Clifton via Binutils wrote: > 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. Nick, the patch you posted is for code with this comment: case SHT_REL: case SHT_RELA: /* A reloc section which we are treating as a normal BFD section. sh_link is the section index of the symbol table. sh_info is the section index of the section to which the relocation entries apply. We assume that an allocated reloc section uses the dynamic symbol table if there is one. Otherwise we guess the normal symbol table. FIXME: How can we be sure? */ ie. we are way off into the weeds already. However, I think the comment is wrongly placed, because it looks to me like we handle the usual SHT_REL/SHT_RELA sections here too. So is the .rela.got (or .rela.plt) section one of the reloc sections created in bfd_section_from_shdr elf.c:2382? If we need to handle this sort of reloc section better (and I doubt we do need to) then we should do something about tracking the original sh_link and sh_info fields when creating them, Hmm, maybe they are still available, and can be mapped to output sections? Anyway, does the following fix the particular problem you are seeing? diff --git a/bfd/elf.c b/bfd/elf.c index 45e53640e8f..027d0143735 100644 --- a/bfd/elf.c +++ b/bfd/elf.c @@ -3870,21 +3870,23 @@ assign_section_numbers (bfd *abfd, struct bfd_link_info *link_info) { case SHT_REL: case SHT_RELA: - /* A reloc section which we are treating as a normal BFD - section. sh_link is the section index of the symbol - table. sh_info is the section index of the section to - which the relocation entries apply. We assume that an - allocated reloc section uses the dynamic symbol table - if there is one. Otherwise we guess the normal symbol - table. FIXME: How can we be sure? */ - if (d->this_hdr.sh_link == 0 && (sec->flags & SEC_ALLOC) != 0) - { - s = bfd_get_section_by_name (abfd, ".dynsym"); - if (s != NULL) - d->this_hdr.sh_link = elf_section_data (s)->this_idx; - } + /* sh_link is the section index of the symbol table. + sh_info is the section index of the section to which the + relocation entries apply. */ if (d->this_hdr.sh_link == 0) - d->this_hdr.sh_link = elf_onesymtab (abfd); + { + /* FIXME maybe: If this is a reloc section which we are + treating as a normal section then we likely should + not be assuming its sh_link is .dynsym or .symtab. */ + if ((sec->flags & SEC_ALLOC) != 0) + { + s = bfd_get_section_by_name (abfd, ".dynsym"); + if (s != NULL) + d->this_hdr.sh_link = elf_section_data (s)->this_idx; + } + else + d->this_hdr.sh_link = elf_onesymtab (abfd); + } s = elf_get_reloc_section (sec); if (s != NULL) -- Alan Modra Australia Development Lab, IBM