Re: gdb compile for powerpc64 target - Could not find symbol ".TOC."

[Ulrich Weigand <uweigand@de.ibm.com>]

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?

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