aboutsummaryrefslogtreecommitdiff
path: root/gdb/ChangeLog
diff options
context:
space:
mode:
authorAndrew Burgess <andrew.burgess@embecosm.com>2019-08-29 12:37:00 +0100
committerAndrew Burgess <andrew.burgess@embecosm.com>2021-06-01 09:23:34 +0100
commitb4b3e2dee20dcde6eb47ebdc6231f5d8edf60ff5 (patch)
tree011709cafd49177bc49f47523f03ef3e772089f8 /gdb/ChangeLog
parenta2cf3633b33ec21b967f4c7ddfb7f1b80e676d2d (diff)
downloadfsf-binutils-gdb-b4b3e2dee20dcde6eb47ebdc6231f5d8edf60ff5.zip
fsf-binutils-gdb-b4b3e2dee20dcde6eb47ebdc6231f5d8edf60ff5.tar.gz
fsf-binutils-gdb-b4b3e2dee20dcde6eb47ebdc6231f5d8edf60ff5.tar.bz2
gdb: avoid premature dummy frame garbage collection
Consider the following chain of events: * GDB is performing an inferior call, and * the inferior calls longjmp, and * GDB detects that the longjmp has completed, stops, and enters check_longjmp_breakpoint_for_call_dummy (in breakpoint.c), and * GDB tries to unwind the stack in order to check that the dummy frame (setup for the inferior call) is still on the stack, but * The unwind fails, possibly due to missing debug information, so * GDB incorrectly concludes that the inferior has longjmp'd past the dummy frame, and so deletes the dummy frame, including the dummy frame breakpoint, but then * The inferior continues, and eventually returns to the dummy frame, which is usually (always?) on the stack, the inferior starts trying to execute the random contents of the stack, this results in undefined behaviour. This situation is already warned about in the comment on the function check_longjmp_breakpoint_for_call_dummy where we say: You should call this function only at places where it is safe to currently unwind the whole stack. Failed stack unwind would discard live dummy frames. The warning here is fine, the problem is that, even though we call the function from a location within GDB where we hope to be able to unwind, sometime the state of the inferior means that the unwind will not succeed. This commit tries to improve the situation by adding the following additional check; when GDB fails to find the dummy frame on the stack, instead of just assuming that the dummy frame can be garbage collected, first find the stop_reason for the last frame on the stack. If this stop_reason indicates that the stack unwinding may have failed then we assume that the dummy frame is still in use. However, if the last frame's stop_reason indicates that the stack unwind completed successfully then we can be confident that the dummy frame is no longer in use, and we garbage collect it. Tested on x86-64 GNU/Linux. gdb/ChangeLog: * breakpoint.c (check_longjmp_breakpoint_for_call_dummy): Add check for why the backtrace stopped. gdb/testsuite/ChangeLog: * gdb.base/premature-dummy-frame-removal.c: New file. * gdb.base/premature-dummy-frame-removal.exp: New file. * gdb.base/premature-dummy-frame-removal.py: New file. Change-Id: I8f330cfe0f3f33beb3a52a36994094c4abada07e
Diffstat (limited to 'gdb/ChangeLog')
-rw-r--r--gdb/ChangeLog6
1 files changed, 6 insertions, 0 deletions
diff --git a/gdb/ChangeLog b/gdb/ChangeLog
index 7581c09..b6930df 100644
--- a/gdb/ChangeLog
+++ b/gdb/ChangeLog
@@ -1,3 +1,9 @@
+2021-06-01 Andrew Burgess <andrew.burgess@embecosm.com>
+ Richard Bunt <richard.bunt@arm.com>
+
+ * breakpoint.c (check_longjmp_breakpoint_for_call_dummy): Add
+ check for why the backtrace stopped.
+
2021-05-31 Simon Marchi <simon.marchi@polymtl.ca>
* dwarf2/read.h (struct structured_type) <signatured_type>: New.