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

[Alan Modra <amodra@gmail.com>]

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