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

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

[will schmidt]

Hi,

I've been looking at the gdb-compile tests on a powerpc64le target.  In
particular the testsuite/gdb.compile/compile-print.exp test.  I've
locally made a change to set a ppc64le_gnu_triplet_regexp value of
"powerpc64le?" to allow gdb to actually find the compiler and libcc1
for this platform.
With this change the simplest tests are successful, i.e. 
	gdb_test "compile print main" 
	gdb_test "compile print/x 256" 


However, anything more complex will fail.  i.e. 
	gdb_test
"compile print varint"

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.

With "set debug compile" enabled, a few bits of possibly relevant
info..

	COLLECT_GCC_OPTIONS='-m64' '-mcmodel=large' '-A' 'system=linux'
	'-A'
'system=unix' '-A' 'system=posix' '-msecure-plt'
	 '-mcpu=power8' '-g' '-fstack-protector-strong' '-std=gnu11'
	 '-fno-exceptions' '-Wno-implicit-function-declaration' '-O0'
	 '-gdwarf-4' '-fPIE' '-Wall' '-Wno-unused-but-set-variable'
	 '-Wno-unused-variable' '-fno-stack-protector'
	 '-fplugin=libcc1plugin' '-fplugin-arg-libcc1plugin-fd=14'
	 '-c' '-o' '/tmp/gdbobj-wIKWtk/out18.o' '-v'

The compiled code (objdump -d out*.o) looks like so:

0000000000000008 <_gdb_expr>:
   8:	f8 ff 4c e8 	ld      r2,-8(r12)
   c:	14 62 42 7c 	add     r2,r2,r12
  10:	f8 ff e1 fb 	std     r31,-8(r1)
  14:	b1 ff 21 f8 	stdu    r1,-80(r1)
  18:	78 0b 3f 7c 	mr      r31,r1
  1c:	30 00 7f f8 	std     r3,48(r31)
  20:	38 00 9f f8 	std     r4,56(r31)
  24:	00 00 22 3d 	addis   r9,r2,0
  28:	00 00 29 e9 	ld      r9,0(r9)
  2c:	02 00 29 e9 	lwa     r9,0(r9)
  30:	20 00 3f 91 	stw     r9,32(r31)
  34:	20 00 5f 81 	lwz     r10,32(r31)
  38:	38 00 3f e9 	ld      r9,56(r31)
  3c:	00 00 49 91 	stw     r10,0(r9)
  40:	00 00 00 60 	nop
  44:	50 00 3f 38 	addi    r1,r31,80
  48:	f8 ff e1 eb 	ld      r31,-8(r1)
  4c:	20 00 80 4e 	blr
	...


I do see the iteration of symbols in compile-object-load(), these
appear to match the (readelf) section header names as indexed by the
(readelf) .symtab table entries. ala:
...
ELF symbol "out18.c" flags [4005]
ELF symbol ".text" flags [1000105]
ELF symbol ".toc" flags [1000105]
ELF symbol ".debug_info" flags [1000105]
ELF symbol ".debug_abbrev" flags [1000105]
ELF symbol ".debug_line" flags [1000105]
ELF symbol ".debug_str" flags [1000105]
ELF symbol ".debug_frame" flags [1000105]
ELF symbol "_gdb_expr" flags [a]
ELF symbol ".TOC." flags [0]

Per "readelf -a" against the generated .o file, i can see:

Symbol table '.symtab' contains 11 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS out5.c
     2: 0000000000000000     0 SECTION LOCAL  DEFAULT    1 
     3: 0000000000000000     0 SECTION LOCAL  DEFAULT    5 
     4: 0000000000000000     0 SECTION LOCAL  DEFAULT    6 
     5: 0000000000000000     0 SECTION LOCAL  DEFAULT    8 
     6: 0000000000000000     0 SECTION LOCAL  DEFAULT   11 
     7: 0000000000000000     0 SECTION LOCAL  DEFAULT   13 
     8: 0000000000000000     0 SECTION LOCAL  DEFAULT   16 
     9: 0000000000000008    84 FUNC    GLOBAL DEFAULT [<localentry>: 8]     1 _gdb_expr
    10: 0000000000000000     0 NOTYPE  GLOBAL DEFAULT  UND .TOC.


Relocation section '.rela.text' at offset 0x6a8 contains 4 entries:
  Offset          Info           Type           Sym. Value    Sym. Name + Addend
000000000000  000a0000002c R_PPC64_REL64     0000000000000000 .TOC. - 8
000000000008  000000000076 R_PPC64_ENTRY                        0
000000000024  000300000032 R_PPC64_TOC16_HA  0000000000000000 .toc + 0
000000000028  000300000040 R_PPC64_TOC16_LO_ 0000000000000000 .toc + 0



Any hints or advice on how to chase this further are welcomed. 
Thanks
-Will

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

[Ulrich Weigand]

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.

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.

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.

Bye,
Ulricj

-- 
  Dr. Ulrich Weigand
  GNU/Linux compilers and toolchain
  Ulrich.Weigand@de.ibm.com

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

[will schmidt]

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

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

[Alan Modra]

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

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

[Alan Modra]

On Thu, Jun 24, 2021 at 12:41:18PM +0930, Alan Modra wrote:
> 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.

Ignore that remark about bfd_object.  I had it backwards.

-- 
Alan Modra
Australia Development Lab, IBM

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

[Ulrich Weigand]

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

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

[Alan Modra]

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

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

[will schmidt]

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

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

[will schmidt]

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

Hi,

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

I've made some local changes so I'm now calling bfd_set_gp_value when
the ".TOC." symbol is handled in compile_object_load. 
i.e. 
      if (strcmp (sym->name, ".TOC.") == 0)
        bfd_set_gp_value(abfd.get(), sym->value);

This is either wrong, or insufficient.  :-)

By plugging in different values in place of "sym->value" I can see that
this affects a ld/lwa sequence later on, and I wonder if the offsets we
are trying to load from are simply too large here.

Some helpful(?) debug and recap,..
Our test is a "(gdb) compile print varint"  per
gdb/testsuite/compile/compile-print.exp.  I've changed the varint value
to 0x12345678 to server better as an eyecatcher.
I've got a small number of local changes allowing us to at least find
our compiler (patch attached for reference).

When we enter _gdb_expr, r12 points to the function entry point, so 
in this case has the value 0x0000200000080000. 

>(gdb) disas
>Dump of assembler code for function _gdb_expr:
>    0x0000200000080000 <+0>:	addis   r2,r12,-8
>    0x0000200000080004 <+4>:	addi    r2,r2,0
>    0x0000200000080008 <+8>:	std     r31,-8(r1)
>    0x000020000008000c <+12>:	stdu    r1,-80(r1)
>    0x0000200000080010 <+16>:	mr      r31,r1
>    0x0000200000080014 <+20>:	std     r3,48(r31)
>    0x0000200000080018 <+24>:	std     r4,56(r31)
>    0x000020000008001c <+28>:	addis   r9,r2,0         <<--[1]
>    0x0000200000080020 <+32>:	ld      r9,-32768(r9)	<<--[2]
> => 0x0000200000080024 <+36>:	lwa     r9,0(r9)	<<--[3]
>    0x0000200000080028 <+40>:	stw     r9,32(r31)
>    0x000020000008002c <+44>:	lwz     r10,32(r31)
>    0x0000200000080030 <+48>:	ld      r9,56(r31)
>    0x0000200000080034 <+52>:	stw     r10,0(r9)
>    0x0000200000080038 <+56>:	nop
>    0x000020000008003c <+60>:	addi    r1,r31,80
>    0x0000200000080040 <+64>:	ld      r31,-8(r1)
>    0x0000200000080044 <+68>:	blr
> 

Passing in different values to bfd_set_gp_value in place of
sym->value affects the offsets referenced at [1] and [2].

The value in r9 when we reach [3] is zero, so it SIGSEGVs on
that.    The familiar -32768 value at [2] suggests to me
that we are trying to reach farther than allowed.


(gdb) info reg r2
r2             0x200000000000      0x200000000000
(gdb) info reg r12
r12            0x200000080000      0x200000080000

(gdb) info address varint
Symbol "varint" is static storage at address 0x100020010.

(gdb) maint info section .data
Exec file: `/home/willschm/gdb_builds/gdb-patches/a.out', 
        file type elf64-powerpcle.
 [21]     0x100020000->0x100020038 at 0x00010000: .data ALLOC LOAD DATA HAS_CONTENTS

(gdb) find 0x100020000,0x100020038,0x12345678
0x100020010 <varint>
1 pattern found.

(gdb) find 0x200000000000,0x200000080000,0x12345678
Pattern not found.
(gdb) find 0x200000080000,0x200000180000,0x12345678
Pattern not found.




As another reference, this is what the disassembly looks like when we
issue a "compile print main", which does not have any .TOC. references.
(this works).

> (gdb) disas
> Dump of assembler code for function _gdb_expr:
>    0x0000200000080000 <+0>:	std     r31,-8(r1)
>    0x0000200000080004 <+4>:	stdu    r1,-80(r1)
>    0x0000200000080008 <+8>:	mr      r31,r1
>    0x000020000008000c <+12>:	std     r3,48(r31)
>    0x0000200000080010 <+16>:	std     r4,56(r31)
>    0x0000200000080014 <+20>:	lis     r9,1
>    0x0000200000080018 <+24>:	rldicr  r9,r9,16,47
>    0x000020000008001c <+28>:	ori     r9,r9,2044
>    0x0000200000080020 <+32>:	std     r9,32(r31)
>    0x0000200000080024 <+36>:	ld      r9,32(r31)
>    0x0000200000080028 <+40>:	lbz     r10,0(r9)
>    0x000020000008002c <+44>:	ld      r9,56(r31)
>    0x0000200000080030 <+48>:	stb     r10,0(r9)
>    0x0000200000080034 <+52>:	nop
>    0x0000200000080038 <+56>:	addi    r1,r31,80
>    0x000020000008003c <+60>:	ld      r31,-8(r1)
>    0x0000200000080040 <+64>:	blr
>    0x0000200000080044 <+68>:	.long 0x0
>    0x0000200000080048 <+72>:	.long 0x0
>    0x000020000008004c <+76>:	.long 0x1000180
> 


Help!  :-) 

Thanks
-Will


Patches for reference,   
1 - add target options.
2 - add/specify target triple.
3 - externalize bfd bfd_set_gp_value.
4 - call bfd_set_gp_value for .TOC.


[Add target options]

    Add a ppc64_linux_gcc_target_options

diff --git a/gdb/rs6000-tdep.c b/gdb/rs6000-tdep.c
index a629450d746..5c2390f0e41 100644
--- a/gdb/rs6000-tdep.c
+++ b/gdb/rs6000-tdep.c
@@ -822,10 +822,18 @@ rs6000_stack_frame_destroyed_p (struct gdbarch *gdbarch, CORE_ADDR pc)
 {
   return rs6000_in_function_epilogue_frame_p (get_current_frame (),
 					      gdbarch, pc);
 }
 
+/* Implement  the linux_gcc_target_options method.  */
+static std::string
+ppc64_linux_gcc_target_options (struct gdbarch *gdbarch)
+{
+        return "-mcmodel=medium" ;
+}
+
+
 /* Get the ith function argument for the current function.  */
 static CORE_ADDR
 rs6000_fetch_pointer_argument (struct frame_info *frame, int argi, 
 			       struct type *type)
 {
@@ -7127,10 +7135,13 @@ rs6000_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches)
   /* Trampoline.  */
   set_gdbarch_in_solib_return_trampoline
     (gdbarch, rs6000_in_solib_return_trampoline);
   set_gdbarch_skip_trampoline_code (gdbarch, rs6000_skip_trampoline_code);
 
+  /* */
+  set_gdbarch_gcc_target_options (gdbarch, ppc64_linux_gcc_target_options);
+
   /* Hook in the DWARF CFI frame unwinder.  */
   dwarf2_append_unwinders (gdbarch);
   dwarf2_frame_set_adjust_regnum (gdbarch, rs6000_adjust_frame_regnum);
 
   /* Frame handling.  */



[Add target triplet]

    add a target triplet.  (needs adjustment)

diff --git a/gdb/ppc-linux-tdep.c b/gdb/ppc-linux-tdep.c
index 1e94922f25a..61a69a5de78 100644
--- a/gdb/ppc-linux-tdep.c
+++ b/gdb/ppc-linux-tdep.c
@@ -1971,10 +1971,17 @@ ppc_floatformat_for_type (struct gdbarch *gdbarch,
     }
 
   return default_floatformat_for_type (gdbarch, name, len);
 }
 
+/* Specify the target triplet as appropriate.. */
+static const char *
+ppc64le_gnu_triplet_regexp (struct gdbarch *gdbarch)
+{
+        return "powerpc64le?";
+}
+
 static void
 ppc_linux_init_abi (struct gdbarch_info info,
 		    struct gdbarch *gdbarch)
 {
   struct gdbarch_tdep *tdep = gdbarch_tdep (gdbarch);
@@ -2101,10 +2108,13 @@ ppc_linux_init_abi (struct gdbarch_info info,
       /* BFD target for core files.  */
       if (gdbarch_byte_order (gdbarch) == BFD_ENDIAN_LITTLE)
 	set_gdbarch_gcore_bfd_target (gdbarch, "elf64-powerpcle");
       else
 	set_gdbarch_gcore_bfd_target (gdbarch, "elf64-powerpc");
+     /* Set compiler triplet.  */
+      if (gdbarch_byte_order (gdbarch) == BFD_ENDIAN_LITTLE)
+          set_gdbarch_gnu_triplet_regexp (gdbarch, ppc64le_gnu_triplet_regexp);
     }
 
   set_gdbarch_core_read_description (gdbarch, ppc_linux_core_read_description);
   set_gdbarch_iterate_over_regset_sections (gdbarch,
 					    ppc_linux_iterate_over_regset_sections);



[ eternalize bfd bfd_set_gp_value ]

    tweak bfd to externalize the bfd_set_gp_value function.

diff --git a/bfd/bfd.c b/bfd/bfd.c
index 6e5d3397d15..a53ad80190e 100644
--- a/bfd/bfd.c
+++ b/bfd/bfd.c
@@ -1849,10 +1849,28 @@ _bfd_set_gp_value (bfd *abfd, bfd_vma v)
     ecoff_data (abfd)->gp = v;
   else if (abfd->xvec->flavour == bfd_target_elf_flavour)
     elf_gp (abfd) = v;
 }
 
+/*
+FUNCTION
+	bfd_set_gp_value
+
+SYNOPSIS
+	void bfd_set_gp_value (bfd * abfd, bfd_vma v);
+
+DESCRIPTION
+	Allow external gdb to call this function for
+	gdb-compile support.
+*/
+
+void
+bfd_set_gp_value (bfd *abfd, bfd_vma v)
+{
+        return _bfd_set_gp_value (abfd, v);
+}
+
 /*
 FUNCTION
 	bfd_scan_vma
 
 SYNOPSIS




[ call bfd_set_gp_value for .TOC. symbol ]

diff --git a/gdb/compile/compile-object-load.c b/gdb/compile/compile-object-load.c
index 1c512801bcd..56df153a89c 100644
--- a/gdb/compile/compile-object-load.c
+++ b/gdb/compile/compile-object-load.c
@@ -720,10 +720,27 @@ compile_object_load (const compile_file_names &file_names,
 	     need for _GLOBAL_OFFSET_TABLE_.  Together with -fPIE the data
 	     remain PC-relative even with _GLOBAL_OFFSET_TABLE_ as zero.  */
 	  sym->value = 0;
 	  continue;
 	}
+      if (strcmp (sym->name, ".TOC.") == 0)
+        {
+	  fprintf_unfiltered (gdb_stdlog,
+			      "ELF symbol \"%s\" found.  calling bfd_set_gp_value %s\n",
+			      sym->name, paddress (target_gdbarch (), sym->value));
+	  bfd_set_gp_value(abfd.get(), sym->value);
+	  continue;
+        }
+      /* debug ... */
+      if (strcmp (sym->name, "varint") == 0)
+        {
+	  fprintf_unfiltered (gdb_stdlog,
+			      "ELF symbol \"%s\" found. value  is %s\n",
+			      sym->name, paddress (target_gdbarch (), sym->value));
+	  continue;
+        }
+
       bmsym = lookup_minimal_symbol (sym->name, NULL, NULL);
       switch (bmsym.minsym == NULL
 	      ? mst_unknown : MSYMBOL_TYPE (bmsym.minsym))
 	{
 	case mst_text:




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






> 

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

[Alan Modra]

On Fri, Jul 09, 2021 at 11:51:35AM -0500, will schmidt wrote:
> I've made some local changes so I'm now calling bfd_set_gp_value when
> the ".TOC." symbol is handled in compile_object_load. 
> i.e. 
>       if (strcmp (sym->name, ".TOC.") == 0)
>         bfd_set_gp_value(abfd.get(), sym->value);
> 
> This is either wrong, or insufficient.  :-)

Symbol value here is section relative.  You need to add the symbol
section vma, which is set by setup_sections_data::setup_one_section.

If that doesn't help, I would run gdb under gdb with a breakpoint on
ppc64_elf_toc_reloc looking to see whether that function is using the
value you expect given your bfd_set_gp_value call.

-- 
Alan Modra
Australia Development Lab, IBM

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

[will schmidt]

On Sat, 2021-07-10 at 10:31 +0930, Alan Modra wrote:
> On Fri, Jul 09, 2021 at 11:51:35AM -0500, will schmidt wrote:
> > I've made some local changes so I'm now calling bfd_set_gp_value
> > when
> > the ".TOC." symbol is handled in compile_object_load. 
> > i.e. 
> >       if (strcmp (sym->name, ".TOC.") == 0)
> >         bfd_set_gp_value(abfd.get(), sym->value);
> > 
> > This is either wrong, or insufficient.  :-)
> 
> Symbol value here is section relative.  You need to add the symbol
> section vma, which is set by setup_sections_data::setup_one_section.


So is that creating a new section named vma, or updating one of the
existing sections?
I see that we currently call setup_one_section for all(?) of the
sections , the full list being .data, .bss, .toc, .debug_info,
.debug_abbrev, .debug_aranges, .debug_line, .debug_str, .comment,
.note.GNU-stack, .debug_frame.   
It appears we call bfd_set_section_vma (sect, m_last_size);  for each
of those.
I can't immediately tell if or how I should try adding a call to
bfd_set_gp_value from within there.    (how to get to the parent abfd
from within a scope that only deals with the section?)
If/when I sort that part out, I'm still not sure what value I should be
trying to set that gp value to.  :-)

> 
> If that doesn't help, I would run gdb under gdb with a breakpoint on
> ppc64_elf_toc_reloc looking to see whether that function is using the
> value you expect given your bfd_set_gp_value call.

At the moment (before further changes)..


(gdbouter) p TOCstart
$42 = 01000000002200000


Thanks
-Will

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

[Alan Modra]

On Mon, Jul 12, 2021 at 11:33:05PM -0500, will schmidt wrote:
> On Sat, 2021-07-10 at 10:31 +0930, Alan Modra wrote:
> > On Fri, Jul 09, 2021 at 11:51:35AM -0500, will schmidt wrote:
> > > I've made some local changes so I'm now calling bfd_set_gp_value
> > > when
> > > the ".TOC." symbol is handled in compile_object_load. 
> > > i.e. 
> > >       if (strcmp (sym->name, ".TOC.") == 0)
> > >         bfd_set_gp_value(abfd.get(), sym->value);
> > > 
> > > This is either wrong, or insufficient.  :-)
> > 
> > Symbol value here is section relative.  You need to add the symbol
> > section vma, which is set by setup_sections_data::setup_one_section.
> 
> 
> So is that creating a new section named vma, or updating one of the
> existing sections?

sym is of type asymbol*, one of the fields of asymbol is "section".  I
was referring to sym->section->vma when I wrote the above, but on
thinking about it some more, I see that won't be correct.  We aren't
performing a final link here, just loading up object files and trying
to stitch them together.  So I think you'll find that the
.TOC. sym->section is bfd_und_section_ptr.  You'll need to do as the
linker would, set both the .TOC symbol value and section, then pass
the sym->value + sym->section->vma - 0x8000 to bfd_set_gp_value.
(Somewhat oddly, the ppc64 bfd code defines a gp_value offset by
0x8000, ie. what would normally be the start of the TOC given an
initial toc pointer or .TOC. at 0x8000 into that section.)

Something like

      if (strcmp (sym->name, ".TOC.") == 0)
	{
	  asection *toc = bfd_get_section_by_name (abfd.get(), ".toc");
	  sym->section = toc;
	  sym->value = 0x8000;
	  bfd_set_gp_value (abfd.get(), toc);
	}

What to do on not finding a .toc section I'll leave as an exercise.

> I see that we currently call setup_one_section for all(?) of the
> sections , the full list being .data, .bss, .toc, .debug_info,
> .debug_abbrev, .debug_aranges, .debug_line, .debug_str, .comment,
> .note.GNU-stack, .debug_frame.   
> It appears we call bfd_set_section_vma (sect, m_last_size);  for each
> of those.
> I can't immediately tell if or how I should try adding a call to
> bfd_set_gp_value from within there.    (how to get to the parent abfd
> from within a scope that only deals with the section?)

section->owner gives the parent bfd, but it is probably tidier to
leave calling bfd_set_gp_value to when you find you have a
.TOC. symbol.  The point being that the only reason you have to do
anything about the gp_value is to force the value used in relocations
against the .TOC. symbol to agree with the value used by all the
R_PPC64_TOC* relocations.

> If/when I sort that part out, I'm still not sure what value I should be
> trying to set that gp value to.  :-)
> 
> > 
> > If that doesn't help, I would run gdb under gdb with a breakpoint on
> > ppc64_elf_toc_reloc looking to see whether that function is using the
> > value you expect given your bfd_set_gp_value call.
> 
> At the moment (before further changes)..
> 
> 
> (gdbouter) p TOCstart
> $42 = 01000000002200000
> 
> 
> Thanks
> -Will

-- 
Alan Modra
Australia Development Lab, IBM

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

[will schmidt]

On Tue, 2021-07-13 at 20:41 +0930, Alan Modra wrote:
> On Mon, Jul 12, 2021 at 11:33:05PM -0500, will schmidt wrote:
> > On Sat, 2021-07-10 at 10:31 +0930, Alan Modra wrote:
> > > On Fri, Jul 09, 2021 at 11:51:35AM -0500, will schmidt wrote:
> > > > I've made some local changes so I'm now calling
> > > > bfd_set_gp_value
> > > > when
> > > > the ".TOC." symbol is handled in compile_object_load. 
> > > > i.e. 
> > > >       if (strcmp (sym->name, ".TOC.") == 0)
> > > >         bfd_set_gp_value(abfd.get(), sym->value);
> > > > 
> > > > This is either wrong, or insufficient.  :-)
> > > 
> > > Symbol value here is section relative.  You need to add the
> > > symbol
> > > section vma, which is set by
> > > setup_sections_data::setup_one_section.
> > 
> > 
> > So is that creating a new section named vma, or updating one of the
> > existing sections?
> 
> sym is of type asymbol*, one of the fields of asymbol is
> "section".  I
> was referring to sym->section->vma when I wrote the above, but on
> thinking about it some more, I see that won't be correct.  We aren't
> performing a final link here, just loading up object files and trying
> to stitch them together.  So I think you'll find that the
> .TOC. sym->section is bfd_und_section_ptr.  You'll need to do as the
> linker would, set both the .TOC symbol value and section, then pass
> the sym->value + sym->section->vma - 0x8000 to bfd_set_gp_value.
> (Somewhat oddly, the ppc64 bfd code defines a gp_value offset by
> 0x8000, ie. what would normally be the start of the TOC given an
> initial toc pointer or .TOC. at 0x8000 into that section.)

Thanks! :-)

> Something like
> 
>       if (strcmp (sym->name, ".TOC.") == 0)
> 	{
> 	  asection *toc = bfd_get_section_by_name (abfd.get(), ".toc");
> 	  sym->section = toc;
> 	  sym->value = 0x8000;
> 	  bfd_set_gp_value (abfd.get(), toc);

That last line changed to this seems to work:
  bfd_set_gp_value(abfd.get(), sym->value + sym->section->vma -
0x8000);
Which is as you described it in the paragraph above.  :-)

At this time the gdb.compile set of tests looks much better.. 

> make check RUNTESTFLAGS="gdb.compile/compile-*.exp"
> ...
> 		=== gdb Summary ===
> 
> # of expected passes		97
> # of unexpected failures	39
> # of known failures		17
> # of unresolved testcases	6

I have several weeks worth of debug/hack code in place now, fingers
crossed a bunch of those failures clear up once I get my debug junk out
of the way.
I'll post a clean set of patches when they are ready,.. 

Thanks
-WIll



> 	}
> 
> What to do on not finding a .toc section I'll leave as an exercise.
> 
> > I see that we currently call setup_one_section for all(?) of the
> > sections , the full list being .data, .bss, .toc, .debug_info,
> > .debug_abbrev, .debug_aranges, .debug_line, .debug_str, .comment,
> > .note.GNU-stack, .debug_frame.   
> > It appears we call bfd_set_section_vma (sect, m_last_size);  for
> > each
> > of those.
> > I can't immediately tell if or how I should try adding a call to
> > bfd_set_gp_value from within there.    (how to get to the parent
> > abfd
> > from within a scope that only deals with the section?)
> 
> section->owner gives the parent bfd, but it is probably tidier to
> leave calling bfd_set_gp_value to when you find you have a
> .TOC. symbol.  The point being that the only reason you have to do
> anything about the gp_value is to force the value used in relocations
> against the .TOC. symbol to agree with the value used by all the
> R_PPC64_TOC* relocations.
> 
> > If/when I sort that part out, I'm still not sure what value I
> > should be
> > trying to set that gp value to.  :-)
> > 
> > > 
> > > If that doesn't help, I would run gdb under gdb with a breakpoint
> > > on
> > > ppc64_elf_toc_reloc looking to see whether that function is using
> > > the
> > > value you expect given your bfd_set_gp_value call.
> > 
> > At the moment (before further changes)..
> > 
> > 
> > (gdbouter) p TOCstart
> > $42 = 01000000002200000
> > 
> > 
> > Thanks
> > -Will
> 
>