aboutsummaryrefslogtreecommitdiff
path: root/gdb/frame-id.h
diff options
context:
space:
mode:
authorBruno Larsen <blarsen@redhat.com>2022-07-25 14:06:37 -0300
committerBruno Larsen <blarsen@redhat.com>2022-10-10 11:57:10 +0200
commitc29a6445a981cee5e8eebe3617ef5c049fd3409f (patch)
treebdaf7bc8b1e30feb35995b1be6d1e059c680e7fd /gdb/frame-id.h
parentbd2b40ac129b167f1a709589dee9c009a04a6e21 (diff)
downloadfsf-binutils-gdb-c29a6445a981cee5e8eebe3617ef5c049fd3409f.zip
fsf-binutils-gdb-c29a6445a981cee5e8eebe3617ef5c049fd3409f.tar.gz
fsf-binutils-gdb-c29a6445a981cee5e8eebe3617ef5c049fd3409f.tar.bz2
gdb/frame: Add reinflation method for frame_info_ptr
Currently, despite having a smart pointer for frame_infos, GDB may attempt to use an invalidated frame_info_ptr, which would cause internal errors to happen. One such example has been documented as PR python/28856, that happened when printing frame arguments calls an inferior function. To avoid failures, the smart wrapper was changed to also cache the frame id, so the pointer can be reinflated later. For this to work, the frame-id stuff had to be moved to their own .h file, which is included by frame-info.h. Frame_id caching is done explicitly using the prepare_reinflate method. Caching is done manually so that only the pointers that need to be saved will be, and reinflating has to be done manually using the reinflate method because the get method and the -> operator must not change the internals of the class. Finally, attempting to reinflate when the pointer is being invalidated causes the following assertion errors: check_ptrace_stopped_lwp_gone: assertion `lp->stopped` failed. get_frame_pc: Assertion `frame->next != NULL` failed. As for performance concerns, my personal testing with `time make chec-perf GDB_PERFTEST_MODE=run` showed an actual reduction of around 10% of time running. This commit also adds a testcase that exercises the python/28856 bug with 7 different triggers, run, continue, step, backtrace, finish, up and down. Some of them can seem to be testing the same thing twice, but since this test relies on stale pointers, there is always a chance that GDB got lucky when testing, so better to test extra. Regression tested on x86_64, using both gcc and clang. Approved-by: Tom Tomey <tom@tromey.com>
Diffstat (limited to 'gdb/frame-id.h')
-rw-r--r--gdb/frame-id.h135
1 files changed, 135 insertions, 0 deletions
diff --git a/gdb/frame-id.h b/gdb/frame-id.h
new file mode 100644
index 0000000..142488f
--- /dev/null
+++ b/gdb/frame-id.h
@@ -0,0 +1,135 @@
+/* Definitions for dealing with stack frames, for GDB, the GNU debugger.
+
+ Copyright (C) 1986-2022 Free Software Foundation, Inc.
+
+ This file is part of GDB.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+#ifndef GDB_FRAME_ID_H
+#define GDB_FRAME_ID_H 1
+
+/* Status of a given frame's stack. */
+
+enum frame_id_stack_status
+{
+ /* Stack address is invalid. */
+ FID_STACK_INVALID = 0,
+
+ /* Stack address is valid, and is found in the stack_addr field. */
+ FID_STACK_VALID = 1,
+
+ /* Sentinel frame. */
+ FID_STACK_SENTINEL = 2,
+
+ /* Outer frame. Since a frame's stack address is typically defined as the
+ value the stack pointer had prior to the activation of the frame, an outer
+ frame doesn't have a stack address. The frame ids of frames inlined in the
+ outer frame are also of this type. */
+ FID_STACK_OUTER = 3,
+
+ /* Stack address is unavailable. I.e., there's a valid stack, but
+ we don't know where it is (because memory or registers we'd
+ compute it from were not collected). */
+ FID_STACK_UNAVAILABLE = -1
+};
+
+/* The frame object's ID. This provides a per-frame unique identifier
+ that can be used to relocate a `struct frame_info' after a target
+ resume or a frame cache destruct. It of course assumes that the
+ inferior hasn't unwound the stack past that frame. */
+
+struct frame_id
+{
+ /* The frame's stack address. This shall be constant through out
+ the lifetime of a frame. Note that this requirement applies to
+ not just the function body, but also the prologue and (in theory
+ at least) the epilogue. Since that value needs to fall either on
+ the boundary, or within the frame's address range, the frame's
+ outer-most address (the inner-most address of the previous frame)
+ is used. Watch out for all the legacy targets that still use the
+ function pointer register or stack pointer register. They are
+ wrong.
+
+ This field is valid only if frame_id.stack_status is
+ FID_STACK_VALID. It will be 0 for other
+ FID_STACK_... statuses. */
+ CORE_ADDR stack_addr;
+
+ /* The frame's code address. This shall be constant through out the
+ lifetime of the frame. While the PC (a.k.a. resume address)
+ changes as the function is executed, this code address cannot.
+ Typically, it is set to the address of the entry point of the
+ frame's function (as returned by get_frame_func).
+
+ For inlined functions (INLINE_DEPTH != 0), this is the address of
+ the first executed instruction in the block corresponding to the
+ inlined function.
+
+ This field is valid only if code_addr_p is true. Otherwise, this
+ frame is considered to have a wildcard code address, i.e. one that
+ matches every address value in frame comparisons. */
+ CORE_ADDR code_addr;
+
+ /* The frame's special address. This shall be constant through out the
+ lifetime of the frame. This is used for architectures that may have
+ frames that do not change the stack but are still distinct and have
+ some form of distinct identifier (e.g. the ia64 which uses a 2nd
+ stack for registers). This field is treated as unordered - i.e. will
+ not be used in frame ordering comparisons.
+
+ This field is valid only if special_addr_p is true. Otherwise, this
+ frame is considered to have a wildcard special address, i.e. one that
+ matches every address value in frame comparisons. */
+ CORE_ADDR special_addr;
+
+ /* Flags to indicate the above fields have valid contents. */
+ ENUM_BITFIELD(frame_id_stack_status) stack_status : 3;
+ unsigned int code_addr_p : 1;
+ unsigned int special_addr_p : 1;
+
+ /* It is non-zero for a frame made up by GDB without stack data
+ representation in inferior, such as INLINE_FRAME or TAILCALL_FRAME.
+ Caller of inlined function will have it zero, each more inner called frame
+ will have it increasingly one, two etc. Similarly for TAILCALL_FRAME. */
+ int artificial_depth;
+
+ /* Return a string representation of this frame id. */
+ std::string to_string () const;
+
+ /* Returns true when this frame_id and R identify the same
+ frame. */
+ bool operator== (const frame_id &r) const;
+
+ /* Inverse of ==. */
+ bool operator!= (const frame_id &r) const
+ {
+ return !(*this == r);
+ }
+};
+
+/* Methods for constructing and comparing Frame IDs. */
+
+/* For convenience. All fields are zero. This means "there is no frame". */
+extern const struct frame_id null_frame_id;
+
+/* Sentinel frame. */
+extern const struct frame_id sentinel_frame_id;
+
+/* This means "there is no frame ID, but there is a frame". It should be
+ replaced by best-effort frame IDs for the outermost frame, somehow.
+ The implementation is only special_addr_p set. */
+extern const struct frame_id outer_frame_id;
+
+#endif /* ifdef GDB_FRAME_ID_H */