Scott Linder
22b9b4b05b
Remove the restriction (gdb_assert) that prevents creating frames inlined in the outer frame. Like for frames inlined in a standard frame (FID_STACK_VALID), a frame inlined into the outer frame will have: - artificial_depth greater than 0 - code_addr equal to the first executed instruction in the block corresponding to the inlined function It will however have its stack_status set to FID_STACK_OUTER, like the outer frame. This is not typically seen on your everyday system (e.g. a Linux / x86-64 process), because the outer frame would be for instance the _start function, probably written in assembly and very unlikely to have anything inlined in it. However this could happen in more "bare-metal" scenarios. In particular, this was seen in ROCm GDB [1], where the compiler does inline functions in the top-level kernel functions (kernel in the sense of compute kernel, not userspace vs kernel). I however wrote a test that replicates the issue on x86-64 and a few other arches I had access to. Since we need to control precisely the emitted DWARF CFI, I didn't find another way than to write it in assembly. The DWARF is generated using the testsuite's DWARF assembler, except the unwind information, which is written using CFI directives (and therefore generated by the actual assembler). I think the test is adequately commented, but if anything is unclear, just ask and I'll add more info. [1] https://github.com/ROCm-Developer-Tools/ROCgdb/ gdb/ChangeLog: YYYY-MM-DD Scott Linder <scott@scottlinder.com> YYYY-MM-DD Simon Marchi <simon.marchi@efficios.com> * inline-frame.c (inline_frame_this_id): Remove assert that prevents inline frame ids in outer frame. gdb/testsuite/ChangeLog: * gdb.dwarf2/frame-inlined-in-outer-frame.exp: New file. * gdb.dwarf2/frame-inlined-in-outer-frame.S: New file. Change-Id: I8aa129c667dccc31590ffdf426586418493a6ebe
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.