From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52b.google.com (mail-pg1-x52b.google.com [IPv6:2607:f8b0:4864:20::52b]) by sourceware.org (Postfix) with ESMTPS id B53973951825 for ; Tue, 13 Jul 2021 11:11:05 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B53973951825 Received: by mail-pg1-x52b.google.com with SMTP id k20so14314752pgg.7 for ; Tue, 13 Jul 2021 04:11:05 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=YB3GWoieYIsltDzsvhX1L4kFZIe178pun+aksUkRy5k=; b=PrvoBIbViH5/1XBCtf/+vdIN0ED7rwDd6yD/wbOEel2xqiQgrSb1X/JUw4uPoxYnWw 1mKG+OhwI3qWHOWU0jP3YGr22pgT+FaS7PYCHk5FjMkNstEk9vVryU94gCLxZ7CKm0eb 1aHlnDlVcdwLPEWSeyPBDj5Zqxcjpe929wu5lumaJ/YmKl+X8pBCDrKGjIltRf+rFl/0 Y/ARlveeKliu9WFkeKoS2CDmxZCzu2iQi6uL1rcI6Xt+i3gOdhCVG6ZCPaePxKPXFwYN bNpHYlcPUoqFHfxFmyFUff/ybrsj6ypPvBje5Ag/3B+T9xoP7k9tLkCT3KrE7LPr9Hrz 60aw== X-Gm-Message-State: AOAM530mV/ZNz+Bkojx89i9gBzha2k9sx2nwXGo0umRt8etZ82NnrGsq auwUr9pBua+Q3QnIBmB/BDg= X-Google-Smtp-Source: ABdhPJx8U/Tr+iXKCLj+IB8Rv8f60VpOi3Un6X/kjYuG3ZBFArCvaqx69M0SvU7j6KG2zdtWrJLxiw== X-Received: by 2002:a63:d06:: with SMTP id c6mr3702327pgl.121.1626174664869; Tue, 13 Jul 2021 04:11:04 -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 10sm18752377pjc.41.2021.07.13.04.11.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 13 Jul 2021 04:11:04 -0700 (PDT) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id 08B4B1140022; Tue, 13 Jul 2021 20:41:01 +0930 (ACST) Date: Tue, 13 Jul 2021 20:41:01 +0930 From: Alan Modra To: will schmidt Cc: Ulrich Weigand , gdb-patches@sourceware.org, rogerio , "Carl E. Love" Subject: Re: gdb compile for powerpc64 target - Could not find symbol ".TOC." Message-ID: References: <606184731c3ea9b484a098f393ffd1efd8190fe2.camel@vnet.ibm.com> <20210623153630.GA2224@oc3748833570.ibm.com> <01c0a5da1434349f6118c1bfb9f500fd932c77d9.camel@vnet.ibm.com> <20210624153250.GA32407@oc3748833570.ibm.com> <7a410f448ecddd3e5c4175344be639f68ab3be47.camel@vnet.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: X-Spam-Status: No, score=-3033.4 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, 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: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 13 Jul 2021 11:11:07 -0000 On Mon, Jul 12, 2021 at 11:33:05PM -0500, will schmidt wrote: > On Sat, 2021-07-10 at 10:31 +0930, Alan Modra wrote: > > On Fri, Jul 09, 2021 at 11:51:35AM -0500, will schmidt wrote: > > > I've made some local changes so I'm now calling bfd_set_gp_value > > > when > > > the ".TOC." symbol is handled in compile_object_load. > > > i.e. > > > if (strcmp (sym->name, ".TOC.") == 0) > > > bfd_set_gp_value(abfd.get(), sym->value); > > > > > > This is either wrong, or insufficient. :-) > > > > Symbol value here is section relative. You need to add the symbol > > section vma, which is set by setup_sections_data::setup_one_section. > > > So is that creating a new section named vma, or updating one of the > existing sections? sym is of type asymbol*, one of the fields of asymbol is "section". I was referring to sym->section->vma when I wrote the above, but on thinking about it some more, I see that won't be correct. We aren't performing a final link here, just loading up object files and trying to stitch them together. So I think you'll find that the .TOC. sym->section is bfd_und_section_ptr. You'll need to do as the linker would, set both the .TOC symbol value and section, then pass the sym->value + sym->section->vma - 0x8000 to bfd_set_gp_value. (Somewhat oddly, the ppc64 bfd code defines a gp_value offset by 0x8000, ie. what would normally be the start of the TOC given an initial toc pointer or .TOC. at 0x8000 into that section.) Something like if (strcmp (sym->name, ".TOC.") == 0) { asection *toc = bfd_get_section_by_name (abfd.get(), ".toc"); sym->section = toc; sym->value = 0x8000; bfd_set_gp_value (abfd.get(), toc); } What to do on not finding a .toc section I'll leave as an exercise. > I see that we currently call setup_one_section for all(?) of the > sections , the full list being .data, .bss, .toc, .debug_info, > .debug_abbrev, .debug_aranges, .debug_line, .debug_str, .comment, > .note.GNU-stack, .debug_frame. > It appears we call bfd_set_section_vma (sect, m_last_size); for each > of those. > I can't immediately tell if or how I should try adding a call to > bfd_set_gp_value from within there. (how to get to the parent abfd > from within a scope that only deals with the section?) section->owner gives the parent bfd, but it is probably tidier to leave calling bfd_set_gp_value to when you find you have a .TOC. symbol. The point being that the only reason you have to do anything about the gp_value is to force the value used in relocations against the .TOC. symbol to agree with the value used by all the R_PPC64_TOC* relocations. > If/when I sort that part out, I'm still not sure what value I should be > trying to set that gp value to. :-) > > > > > If that doesn't help, I would run gdb under gdb with a breakpoint on > > ppc64_elf_toc_reloc looking to see whether that function is using the > > value you expect given your bfd_set_gp_value call. > > At the moment (before further changes).. > > > (gdbouter) p TOCstart > $42 = 01000000002200000 > > > Thanks > -Will -- Alan Modra Australia Development Lab, IBM