From: Nils-Christian Kempke via Gdb-patches <gdb-patches@sourceware.org>
To: gdb-patches@sourceware.org
Subject: [PATCH v3 1/2] gdb, testsuite: adapt function_range expected name
Date: Tue, 23 Aug 2022 17:36:55 +0200 [thread overview]
Message-ID: <20220823153656.1235982-2-nils-christian.kempke@intel.com> (raw)
In-Reply-To: <20220823153656.1235982-1-nils-christian.kempke@intel.com>
When writing a dwarf testcase for some C++ code I wanted to use the
MACRO_AT_range which in turn uses the function_range proc in dwarf.exp
to extract the bounds of 'main'.
However, the macro failed as GDB prints the C++ 'main' with its
arguments as 'main(int, char**)' or 'main()'.
The reason for this is that in read.c::dwarf2_compute_name we call
c_type_print_args on C++ functions and append their arguments to the
function name. This happens to all C++ functions, but is only visible
when the function doesn't have a linkage name.
An example might make this more clear. Given the following code
>> cat c.cpp
int foo (int a, float b)
{
return 0;
}
int main (int argc, char **argv)
{
return 0;
}
which is legal in both languages, C and C++, and compiling it with
e.g. clang or gcc will make the disassemble command look like:
>> clang --version
clang version 10.0.0-4ubuntu1
...
>> clang -O0 -g ./c.cpp
>> gdb -q ./a.out -ex "start"
...
(gdb) disassemble main
Dump of assembler code for function main(int, char**):
0x0000000000401120 <+0>: push %rbp
0x0000000000401121 <+1>: mov %rsp,%rbp
...
0x0000000000401135 <+21>: ret
End of assembler dump.
(gdb) disassemble foo
Dump of assembler code for function _Z3fooif:
0x0000000000401110 <+0>: push %rbp
0x0000000000401111 <+1>: mov %rsp,%rbp
...
0x000000000040111f <+15>: ret
End of assembler dump.
Note, that main is emitted with its arguments while for foo the linkage
name is being printed, as also visible in its DWARF:
>> objdump ./a.out --dwarf=info | grep "foo" -A3 -B3
<2b> DW_AT_low_pc : 0x401110
<33> DW_AT_high_pc : 0x10
<37> DW_AT_frame_base : 1 byte block: 56 (DW_OP_reg6 (rbp))
<39> DW_AT_linkage_name: (indirect string, offset: 0x39): _Z3fooif
<3d> DW_AT_name : (indirect string, offset: 0x42): foo
<41> DW_AT_decl_file : 1
<42> DW_AT_decl_line : 1
<43> DW_AT_type : <0x9a>
Now, let's rename the C++ file and compile it as C:
>> mv c.cpp c.c
>> clang -O0 -g ./c.c
>> gdb -q ./a.out -ex "start'
...
(gdb) disassemble main
Dump of assembler code for function main:
0x0000000000401120 <+0>: push %rbp
0x0000000000401121 <+1>: mov %rsp,%rbp
...
0x0000000000401135 <+21>: ret
End of assembler dump.
(gdb) disassemble foo
Dump of assembler code for function foo:
0x0000000000401110 <+0>: push %rbp
0x0000000000401111 <+1>: mov %rsp,%rbp
...
0x000000000040111f <+15>: ret
End of assembler dump.
Note, for foo we did not get a linkage name emitted in DWARF, so
it is printed by its name:
>> objdump --dwarf=info ./a.out | grep foo -A3 -B3
<2b> DW_AT_low_pc : 0x401110
<33> DW_AT_high_pc : 0x10
<37> DW_AT_frame_base : 1 byte block: 56 (DW_OP_reg6 (rbp))
<39> DW_AT_name : (indirect string, offset: 0x37): foo
<3d> DW_AT_decl_file : 1
<3e> DW_AT_decl_line : 1
<3f> DW_AT_prototyped : 1
To make the macro and proc work with C++ as well, an optional argument
list was added to the regex matching the function name in the
disassemble command in function_range. This does not change any used
behavior as currently, there exists no C++ test using the proc
function_range.
Signed-off-by: Nils-Christian Kempke <nils-christian.kempke@intel.com>
---
gdb/testsuite/lib/dwarf.exp | 12 ++++++++----
1 file changed, 8 insertions(+), 4 deletions(-)
diff --git a/gdb/testsuite/lib/dwarf.exp b/gdb/testsuite/lib/dwarf.exp
index 3d833e5cd58..b5474ca6ce4 100644
--- a/gdb/testsuite/lib/dwarf.exp
+++ b/gdb/testsuite/lib/dwarf.exp
@@ -391,10 +391,14 @@ proc function_range { func src {options {debug}} } {
}
# Compute the size of the last instruction.
- if { $func_length == 0 } then {
- set func_pattern "$func"
- } else {
- set func_pattern "$func\\+$func_length"
+ # For C++, GDB appends arguments to the names of functions if they don't
+ # have a linkage name. For example, asking gdb to disassemble a C++ main
+ # will print the function name as main() or main(int argc, char **argv).
+ # Take this into account by optionally allowing an argument list after
+ # the function name.
+ set func_pattern "$func\(\?\:\\(\.\*\\)\)?"
+ if { $func_length != 0 } {
+ set func_pattern "$func_pattern\\+$func_length"
}
set test "x/2i $func+$func_length"
gdb_test_multiple $test $test {
--
2.25.1
Intel Deutschland GmbH
Registered Address: Am Campeon 10, 85579 Neubiberg, Germany
Tel: +49 89 99 8853-0, www.intel.de <http://www.intel.de>
Managing Directors: Christin Eisenschmid, Sharon Heck, Tiffany Doon Silva
Chairperson of the Supervisory Board: Nicole Lau
Registered Office: Munich
Commercial Register: Amtsgericht Muenchen HRB 186928
next prev parent reply other threads:[~2022-08-23 15:38 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-08-23 15:36 [PATCH v3 0/2] Handle unnamed template tags in GDB Nils-Christian Kempke via Gdb-patches
2022-08-23 15:36 ` Nils-Christian Kempke via Gdb-patches [this message]
2022-08-23 15:36 ` [PATCH v3 2/2] gdb, dwarf: create symbols for template tags without names Nils-Christian Kempke via Gdb-patches
2022-08-23 19:06 ` Tom Tromey
2022-08-24 8:47 ` Kempke, Nils-Christian via Gdb-patches
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=20220823153656.1235982-2-nils-christian.kempke@intel.com \
--to=gdb-patches@sourceware.org \
--cc=nils-christian.kempke@intel.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