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