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

[Alan Modra <amodra@gmail.com>]

On Wed, Jun 23, 2021 at 12:37:48PM -0500, will schmidt wrote:
> On Wed, 2021-06-23 at 17:36 +0200, Ulrich Weigand wrote:
> > On Tue, Jun 22, 2021 at 01:54:56PM -0500, will schmidt wrote:
> > 
> > > During gdb/compile/compile-object-load.c:
> > > compile-object-load() the following is emitted:
> > > 	warning: Could not find symbol ".TOC." for compiled module 
> > > 	"/tmp/gdbobj-wIKWtk/out15.o".
> > > 
> > > My best guess is that we need to incorporate some amount of special
> > > handling for the TOC entry to help find the symbols we are after. 
> > > But.. I havn't stumbled across anything similar for other targets,
> > > and
> > > I havn't yet gleamed enlightenment looking at the existing code in
> > > compile-object-load.  :-)    As a hack I have tried treating the 
> > > TOC symbol like we do the GOT entry, those attempts will later
> > > crash as
> > > we will trip over a zero dereference when trying to get at the
> > > symbol
> > > to print it.

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.  

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.

> > 
> > 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.

Oh, and another thing, even if you manage to set a value for .TOC.,
bfd_get_relocated_section_contents uses reloc howtos to perform
relocations.  bfd.c:_bfd_get_gp_value is used for all the TOC16
relocs, which means elf_gp should be set to .TOC. and you can't leave
the bfd format as bfd_object.

> > Looks like there is a BFD routine ppc64_elf_set_toc that will define
> > that symbol, but that's probably never called here if you just load
> > a plain object file.
> 
> 
> 
> > 
> > Alan, do you have any suggestions of how to handle this, maybe?
> > 
> > 
> > > With "set debug compile" enabled, a few bits of possibly relevant
> > > info..
> > > 
> > > 	COLLECT_GCC_OPTIONS='-m64' '-mcmodel=large' '-A' 'system=linux'
> > 
> > Can you try without -mcmodel=large ?   The particular reference to
> > the .TOC. symbol you show below originated from this option.
> > However, even without that there may still be references to .TOC.
> 
> Yes..  without specifying mcmodel (defaults to medium?) same result.
> Also just tried with each of large,medium,small in turn.. same results.
> 
> 
> 
> 
> Thanks
> -Will
> 
> > 
> > Bye,
> > Ulricj
> > 

-- 
Alan Modra
Australia Development Lab, IBM