mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2024-11-27 03:51:15 +08:00
82eff6743b
It was pointed out that the recently added gdb.opt/inline-entry.exp test would fail when run using gcc 7 and earlier, on an x86-64 target: https://inbox.sourceware.org/gdb-patches/9fe35ea1-d99b-444d-bd1b-e3a1f108dd77@suse.de Bernd Edlinger points out that, for gcc, the test relies on the -gstatement-frontiers work which was added in gcc 8.x: https://inbox.sourceware.org/gdb-patches/DU2PR08MB10263357597688D9D66EA745CE4242@DU2PR08MB10263.eurprd08.prod.outlook.com For gcc 7.x and older, without the -gstatement-frontiers work, the compiler uses DW_AT_entry_pc differently, which leads to a poorer debug experience. Here is the interesting source line from inline-entry.c: if ((global && bar (1)) || bar (2)) And here's some of the relevant disassembly output: Dump of assembler code for function main: 0x401020 <+0>: mov 0x3006(%rip),%eax (1) 0x401026 <+6>: test %eax,%eax (2) 0x401028 <+8>: mov 0x2ffe(%rip),%eax (3) 0x40102e <+14>: je 0x401038 <main+24> (4) 0x401030 <+16>: sub $0x1,%eax (5) 0x401033 <+19>: jne 0x40103d <main+29> (6) Lines (1), (2), and (4) represent the check of 'global'. However, line (3) is actually the first instruction for 'bar' which has been inlined. Lines (5) and (6) are also part of the first inlined 'bar' function. If the check of 'global' returns false then the first call to 'bar' should never happen, this is accomplished by the branch at (4) being taken. For gcc 8+, gcc generates a DW_AT_entry_pc with the value 0x401030, this is where GDB places a breakpoint for 'bar', and this address is after the branch at line (4), and so, if the call to 'bar' never happens, the breakpoint is never hit. For gcc 7 and older, gcc generates a DW_AT_entry_pc with the value 0x401028, which is the first address associated with the inline 'bar' function. Unfortunately, this address is also before the check of 'global' has completed, this means that GDB hits the 'bar' breakpoint before the inferior has decided if 'bar' should actually be called or not. I don't think there's really much GDB can do in the older gcc versions, we are placing the breakpoint at the entry point, and this is within bar. Given that this test does really depend on the newer gcc behaviour, I think the only sensible solution is to skip this test when an older version of gcc is being used. I've incorporated the check for -gstatement-frontiers support that Bernd suggested and now the test will be skipped for older versions of GCC. Approved-By: Tom de Vries <tdevries@suse.de> |
||
|---|---|---|
| bfd | ||
| binutils | ||
| config | ||
| contrib | ||
| cpu | ||
| elfcpp | ||
| etc | ||
| gas | ||
| gdb | ||
| gdbserver | ||
| gdbsupport | ||
| gnulib | ||
| gold | ||
| gprof | ||
| gprofng | ||
| include | ||
| ld | ||
| libbacktrace | ||
| libctf | ||
| libdecnumber | ||
| libiberty | ||
| libsframe | ||
| opcodes | ||
| readline | ||
| sim | ||
| texinfo | ||
| zlib | ||
| .cvsignore | ||
| .editorconfig | ||
| .gitattributes | ||
| .gitignore | ||
| .pre-commit-config.yaml | ||
| 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 | ||
| SECURITY.txt | ||
| 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.