mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2025-03-07 13:39:43 +08:00
244a9a8101
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>
|
||
|---|---|---|
| bfd | ||
| binutils | ||
| config | ||
| contrib | ||
| cpu | ||
| elfcpp | ||
| etc | ||
| gas | ||
| gdb | ||
| gdbserver | ||
| gdbsupport | ||
| gnulib | ||
| gold | ||
| gprof | ||
| gprofng | ||
| include | ||
| intl | ||
| ld | ||
| libbacktrace | ||
| libctf | ||
| libdecnumber | ||
| libiberty | ||
| opcodes | ||
| readline | ||
| sim | ||
| texinfo | ||
| zlib | ||
| .cvsignore | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| ar-lib | ||
| ChangeLog | ||
| compile | ||
| config-ml.in | ||
| config.guess | ||
| config.rpath | ||
| config.sub | ||
| configure | ||
| configure.ac | ||
| COPYING | ||
| COPYING3 | ||
| COPYING3.LIB | ||
| COPYING.LIB | ||
| COPYING.LIBGLOSS | ||
| COPYING.NEWLIB | ||
| depcomp | ||
| djunpack.bat | ||
| install-sh | ||
| libtool.m4 | ||
| lt~obsolete.m4 | ||
| ltgcc.m4 | ||
| ltmain.sh | ||
| ltoptions.m4 | ||
| ltsugar.m4 | ||
| ltversion.m4 | ||
| MAINTAINERS | ||
| Makefile.def | ||
| Makefile.in | ||
| Makefile.tpl | ||
| makefile.vms | ||
| missing | ||
| mkdep | ||
| mkinstalldirs | ||
| move-if-change | ||
| multilib.am | ||
| README | ||
| README-maintainer-mode | ||
| setup.com | ||
| src-release.sh | ||
| symlink-tree | ||
| test-driver | ||
| ylwrap | ||
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.