From: will schmidt <will_schmidt@vnet.ibm.com>
To: Alan Modra <amodra@gmail.com>, Ulrich Weigand <uweigand@de.ibm.com>
Cc: gdb-patches@sourceware.org, rogerio <rogealve@br.ibm.com>,
"Carl E. Love" <cel@us.ibm.com>
Subject: Re: gdb compile for powerpc64 target - Could not find symbol ".TOC."
Date: Fri, 25 Jun 2021 09:49:30 -0500 [thread overview]
Message-ID: <0de5fe79a598099988995ee4fcc06ee158c4de3d.camel@vnet.ibm.com> (raw)
In-Reply-To: <YNUPtenqZ6/tlttm@squeak.grove.modra.org>
On Fri, 2021-06-25 at 08:35 +0930, Alan Modra wrote:
> 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).
Thanks (Both Uli and Alan) for the roadmap and the explanations and
analysis here. :-)
I'll work on this a bit and see where I end up.
Thanks
-Will
>
> > 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
>
>
next prev parent reply other threads:[~2021-06-25 14:49 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-06-22 18:54 will schmidt
2021-06-23 15:36 ` Ulrich Weigand
2021-06-23 17:37 ` will schmidt
2021-06-24 3:11 ` Alan Modra
2021-06-24 4:39 ` Alan Modra
2021-06-24 15:32 ` Ulrich Weigand
2021-06-24 23:05 ` Alan Modra
2021-06-25 14:49 ` will schmidt [this message]
2021-07-09 16:51 ` will schmidt
2021-07-10 1:01 ` Alan Modra
2021-07-13 4:33 ` will schmidt
2021-07-13 11:11 ` Alan Modra
2021-07-13 22:59 ` will schmidt
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=0de5fe79a598099988995ee4fcc06ee158c4de3d.camel@vnet.ibm.com \
--to=will_schmidt@vnet.ibm.com \
--cc=amodra@gmail.com \
--cc=cel@us.ibm.com \
--cc=gdb-patches@sourceware.org \
--cc=rogealve@br.ibm.com \
--cc=uweigand@de.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).