mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-02 12:37:05 +08:00
61b04dd04a
Currently, gdb.gdb/selftest.exp fails if you build GDB with optimization (-O2, etc.). The reason is that after setting a breakpoint in captured_main, we stop at: ... Breakpoint 1, captured_main_1 (context=<optimized out>) at src/gdb/main.c:492 ... while selftest_setup expects a stop at captured_main. Here, captured_main_1 has been inlined into captured_main, and captured_main has been inlined into gdb_main: ... $ nm ./build/gdb/gdb | egrep ' [tT] .*captured_main|gdb_main' | c++filt 000000000061b950 T gdb_main(captured_main_args*) ... Indeed, the two inlined functions show up in the backtrace: ... (gdb) bt #0 captured_main_1 (context=<optimized out>) at main.c:492 #1 captured_main (data=<optimized out>) at main.c:1147 #2 gdb_main (args=args@entry=0x7fffffffdb80) at main.c:1173 #3 0x000000000040fea5 in main (argc=<optimized out>, argv=<optimized out>) at gdb.c:32 ... We're now stopping at captured_main_1 because commit ddfe970e6bec ("Don't elide all inlined frames") makes GDB present a stop at the innermost inlined frame if the program stopped by a user breakpoint. Now, the selftest.exp testcase explicitly asks to stop at "captured_main", not "captured_main_1", so I'm thinking that it's GDB'S behavior that should be improved. That is what this commit does, by only showing a stop at an inline frame if the user breakpoint was set in that frame's block. Before this commit: (top-gdb) b captured_main Breakpoint 1 at 0x792f99: file src/gdb/main.c, line 492. (top-gdb) r Starting program: build/gdb/gdb Breakpoint 1, captured_main_1 (context=<optimized out>) at src/gdb/main.c:492 492 lim_at_start = (char *) sbrk (0); (top-gdb) After this commit, we now instead get: (top-gdb) b captured_main Breakpoint 1 at 0x791339: file src/gdb/main.c, line 492. (top-gdb) r Starting program: build/gdb/gdb Breakpoint 1, captured_main (data=<optimized out>) at src/gdb/main.c:1147 1147 captured_main_1 (context); (top-gdb) and: (top-gdb) b captured_main_1 Breakpoint 2 at 0x791339: file src/gdb/main.c, line 492. (top-gdb) r Starting program: build/gdb/gdb Breakpoint 2, captured_main_1 (context=<optimized out>) at src/gdb/main.c:492 492 lim_at_start = (char *) sbrk (0); (top-gdb) Note that both captured_main and captured_main_1 resolved to the same address, 0x791339. That is necessary to trigger the issue in question. The gdb.base/inline-break.exp testcase currently does not exercise that, but the new test added by this commit does. That new test fails without the GDB fix and passes with the fix. No regressions on x86-64 GNU/Linux. While at it, the THIS_PC comparison in stopped_by_user_bp_inline_frame is basically a nop, so just remove it -- if a software or hardware breakpoint explains the stop, then it must be that it was installed at the current PC. gdb/ChangeLog: 2018-06-19 Pedro Alves <palves@redhat.com> * inline-frame.c (stopped_by_user_bp_inline_frame): Replace PC parameter with a block parameter. Compare location's block symbol with the frame's block instead of addresses. (skip_inline_frames): Pass the current block instead of the frame's address. Break out as soon as we determine the frame should not be skipped. gdb/testsuite/ChangeLog: 2018-06-19 Pedro Alves <palves@redhat.com> * gdb.opt/inline-break.c (func_inline_callee, func_inline_caller) (func_extern_caller): New. (main): Call func_extern_caller. * gdb.opt/inline-break.exp: Add tests for inline frame skipping logic change.
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.