From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pg1-x52d.google.com (mail-pg1-x52d.google.com [IPv6:2607:f8b0:4864:20::52d]) by sourceware.org (Postfix) with ESMTPS id 6492B3886C5A for ; Thu, 24 Jun 2021 23:05:30 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6492B3886C5A Received: by mail-pg1-x52d.google.com with SMTP id y14so5975793pgs.12 for ; Thu, 24 Jun 2021 16:05:30 -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=/qK3I+WXjS05e/4J8JjbUGpAZDxQlmFcLXOCoK4Tg40=; b=FEI2Wirm0h/wtKS465xMpU6QyOscNKQz3lRmer0nDb2sEEu8z9xhrdMgmJb44yzbEc qy9iqNVQ+le5VCqSvJxJe30Wsn11srZjLGylcXqChZf0gBnjY9nSLLLMtTI3djvUpymB xzs5Rx9UvfwyxOGNaPEQ57aWxtAfMcfQTU1ZNnk6xasxfRlNd+IxiQWCXEcB8TPxwPWg N0Jwhz6CSLftCLLRogkJj5t/xv7ulxKygtZuefreDikHc92V6sAnm8E7Mrw75ONnMYEc wNauyopUuf34/FyDh0F9AZXrIwJ2+Hep3bN4Cs1bfzzDSPQ5FsaB02tPPgS2rhZ98/MU 3kxw== X-Gm-Message-State: AOAM531Le7aUDB+X0f0O6N69iXqs8XfcqeoeH1tnNmYOn7sfipkV+Ng2 eOig2HE1SsrDe6WNA7Xb21s= X-Google-Smtp-Source: ABdhPJwAu4IpDLUZ7OjkekLK5p8VB6ZVxKWmQ7BEEGnEhWiRuBuA7OWWhvG0VG1oErqRDgEgOPslPg== X-Received: by 2002:aa7:8d01:0:b029:2f0:88da:1821 with SMTP id j1-20020aa78d010000b02902f088da1821mr7252093pfe.67.1624575929232; Thu, 24 Jun 2021 16:05:29 -0700 (PDT) Received: from squeak.grove.modra.org ([2406:3400:51d:8cc0:b1b0:6ad9:941:a04b]) by smtp.gmail.com with ESMTPSA id u23sm3775303pgk.38.2021.06.24.16.05.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 24 Jun 2021 16:05:27 -0700 (PDT) Received: by squeak.grove.modra.org (Postfix, from userid 1000) id 05D2B114000B; Fri, 25 Jun 2021 08:35:25 +0930 (ACST) Date: Fri, 25 Jun 2021 08:35:25 +0930 From: Alan Modra To: Ulrich Weigand Cc: gdb-patches@sourceware.org, will schmidt , 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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20210624153250.GA32407@oc3748833570.ibm.com> X-Spam-Status: No, score=-3031.0 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.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) 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: Thu, 24 Jun 2021 23:05:31 -0000 On Thu, Jun 24, 2021 at 05:32:50PM +0200, Ulrich Weigand wrote: > On Thu, Jun 24, 2021 at 12:41:18PM +0930, Alan Modra wrote: > > > I'm not at all familiar with gdb/compile, but it looks like anything > > to do with the GOT is unsupported. I can't see any handling for GOT > > relocs, for example. > > The basic approach seems to be: > - Allocate memory in the inferior for each section > - Use bfd_set_section_vma on all sections to provide the address > - Load the symbol table via bfd_canonicalize_symtab > - Modify the symbol table to provide values for all undefined symbols > (via GDB looking them up in the rest of the inferior) > - Use bfd_get_relocated_section_contents to load the contents of > all sections, using the symbol table from above > > I think the assumption is that bfd_get_relocated_section_contents > will handle any relocation type, including GOT/TOC relocs. > > > Now .TOC. should be handled exactly as _GLOBAL_OFFSET_TABLE_, but > > compile-object-load.c is just broken, I think. You can't set .TOC. or > > _GLOBAL_OFFSET_TABLE_ to zero and expect everything to be rosy, for > > code that uses those symbols. > > Agreed, it looks like this makes the Intel-specific assumption that > code uses PC-relative addressing for everything and does not actually > rely on the value of _GLOBAL_OFFSET_TABLE_. I'm not sure this is > even completely true for Intel, but it certainly isn't on Power. > > > > > Yes, we probably do need a proper value for .TOC. Usually, this > > > > is set by the linker to 0x8000 bytes after the beginning of the .toc > > > > section, I think. > > > > Again, I'm not familiar enough with the gdb compile support to give > > proper advice. If calls to functions in the newly compiled/loaded > > code is always via global entry points then you have some freedom in > > choosing your own .TOC. value. If direct calls to the local entry > > point are made then .TOC. should be set to the value used in whatever > > context is going to call the newly loaded object. That would be > > tricky. > > Inferior calls should always use the global entry point, so that > should be OK. I'm more concerned that we have to use the same > value for .TOC. as will be used by bfd_get_relocated_section_contents > for handling TOC-relative relocations. If we just define a value > for the .TOC. symbol in the symbol table passed to > bfd_get_relocated_section_contents, will this be used? No, just defining .TOC. won't be sufficient. A .TOC. symbol value is used if the symbol is found in the linker hash table, but here we aren't even invoking the linker. I think the gdb code should call _bfd_set_gp_value, but _bfd_set_gp_value is currently an internal BFD function. That would need to change (give _bfd_set_gp_value a FUNCTION, SYNOPSIS, DESCRIPTION function comment, remove the declaration from libbfd-in.h, regenerate with --enable-maintainer-mode). > If so, that might be the easiest fix; simply provide a reasonable > value (e.g. address of the .toc section + 0x8000) in the symbol > table, and everything else ought to work out ... > > Bye, > Ulrich > > -- > Dr. Ulrich Weigand > GNU/Linux compilers and toolchain > Ulrich.Weigand@de.ibm.com -- Alan Modra Australia Development Lab, IBM