public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: will schmidt <will_schmidt@vnet.ibm.com>
To: Ulrich Weigand <Ulrich.Weigand@de.ibm.com>,
	"gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Cc: rogerio <rogealve@br.ibm.com>, "Carl E. Love" <cel@us.ibm.com>
Subject: gdb compile for powerpc64 target - Could not find symbol ".TOC."
Date: Tue, 22 Jun 2021 13:54:56 -0500	[thread overview]
Message-ID: <606184731c3ea9b484a098f393ffd1efd8190fe2.camel@vnet.ibm.com> (raw)

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


             reply	other threads:[~2021-06-22 18:55 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-06-22 18:54 will schmidt [this message]
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
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=606184731c3ea9b484a098f393ffd1efd8190fe2.camel@vnet.ibm.com \
    --to=will_schmidt@vnet.ibm.com \
    --cc=Ulrich.Weigand@de.ibm.com \
    --cc=cel@us.ibm.com \
    --cc=gdb-patches@sourceware.org \
    --cc=rogealve@br.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).