From: "Scott Linder (Code Review)" <gerrit@gnutoolchain-gerrit.osci.io>
To: gdb-patches@sourceware.org
Subject: [review] [gdb] Support frames inlined into the outer frame
Date: Wed, 18 Mar 2020 16:17:31 -0400 [thread overview]
Message-ID: <gerrit.1584562651000.I8aa129c667dccc31590ffdf426586418493a6ebe@gnutoolchain-gerrit.osci.io> (raw)
In-Reply-To: <gerrit.1584562651000.I8aa129c667dccc31590ffdf426586418493a6ebe@gnutoolchain-gerrit.osci.io>
Change URL: https://gnutoolchain-gerrit.osci.io/r/c/binutils-gdb/+/767
......................................................................
[gdb] Support frames inlined into the outer frame
Broaden the definition of `outer_frame_id` to effectively create a new
class of "invalid" IDs to represent frames inlined into the outer frame.
These new IDs behave like the outer frame, in that they are "invalid",
yet return true from `frame_id_p` and compare equal to themselves.
2020-03-18 Scott Linder <scott@scottlinder.com>
* frame.c (frame_id_p): Consider functions inlined into outer frame
as valid.
(frame_id_eq): Consider functions inlined into outer frame with same
artificial_depth as equal.
* frame.h (outer_frame_id): Update comment.
(frame_id_p): Update comment.
* inline-frame.c (inline_frame_this_id): Remove assert that prevents
inline frame ids in outer frame.
Change-Id: I8aa129c667dccc31590ffdf426586418493a6ebe
---
M gdb/frame.c
M gdb/frame.h
M gdb/inline-frame.c
3 files changed, 10 insertions(+), 12 deletions(-)
diff --git a/gdb/frame.c b/gdb/frame.c
index d74d1d5..b62d68f 100644
--- a/gdb/frame.c
+++ b/gdb/frame.c
@@ -694,8 +694,8 @@
/* The frame is valid iff it has a valid stack address. */
p = l.stack_status != FID_STACK_INVALID;
- /* outer_frame_id is also valid. */
- if (!p && memcmp (&l, &outer_frame_id, sizeof (l)) == 0)
+ /* outer_frame_id and functions inlined into it are also valid. */
+ if (!p && l.special_addr_p)
p = 1;
if (frame_debug)
{
@@ -722,12 +722,13 @@
if (l.stack_status == FID_STACK_INVALID && l.special_addr_p
&& r.stack_status == FID_STACK_INVALID && r.special_addr_p)
- /* The outermost frame marker is equal to itself. This is the
- dodgy thing about outer_frame_id, since between execution steps
+ /* The outermost frame marker, and any inline frame markers
+ derived from it, are equal to themselves. This is the dodgy
+ thing about outer_frame_id, since between execution steps
we might step into another function - from which we can't
unwind either. More thought required to get rid of
outer_frame_id. */
- eq = 1;
+ eq = l.artificial_depth == r.artificial_depth;
else if (l.stack_status == FID_STACK_INVALID
|| r.stack_status == FID_STACK_INVALID)
/* Like a NaN, if either ID is invalid, the result is false.
diff --git a/gdb/frame.h b/gdb/frame.h
index cfc1502..d394382 100644
--- a/gdb/frame.h
+++ b/gdb/frame.h
@@ -195,7 +195,8 @@
/* 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. */
+ The implementation is only special_addr_p, and possibly
+ artificial_depth, set. */
extern const struct frame_id outer_frame_id;
/* Flag to control debugging. */
@@ -237,8 +238,8 @@
extern struct frame_id frame_id_build_wild (CORE_ADDR stack_addr);
/* Returns non-zero when L is a valid frame (a valid frame has a
- non-zero .base). The outermost frame is valid even without an
- ID. */
+ non-zero .base). The outermost frame and any frames inlined into it
+ are valid even without an ID. */
extern int frame_id_p (struct frame_id l);
/* Returns non-zero when L is a valid frame representing a frame made up by GDB
diff --git a/gdb/inline-frame.c b/gdb/inline-frame.c
index c650195..a187630 100644
--- a/gdb/inline-frame.c
+++ b/gdb/inline-frame.c
@@ -171,10 +171,6 @@
frame"). This will take work. */
gdb_assert (frame_id_p (*this_id));
- /* For now, require we don't match outer_frame_id either (see
- comment above). */
- gdb_assert (!frame_id_eq (*this_id, outer_frame_id));
-
/* Future work NOTE: Alexandre Oliva applied a patch to GCC 4.3
which generates DW_AT_entry_pc for inlined functions when
possible. If this attribute is available, we should use it
--
Gerrit-Project: binutils-gdb
Gerrit-Branch: master
Gerrit-Change-Id: I8aa129c667dccc31590ffdf426586418493a6ebe
Gerrit-Change-Number: 767
Gerrit-PatchSet: 1
Gerrit-Owner: Scott Linder <scott@scottlinder.com>
Gerrit-MessageType: newchange
next parent reply other threads:[~2020-03-18 20:17 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-18 20:17 Scott Linder (Code Review) [this message]
2020-03-18 20:33 ` Simon Marchi (Code Review)
2020-03-18 21:09 ` Scott Linder (Code Review)
2020-03-18 21:10 ` Scott Linder (Code Review)
2020-03-18 21:23 ` Simon Marchi (Code Review)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=gerrit.1584562651000.I8aa129c667dccc31590ffdf426586418493a6ebe@gnutoolchain-gerrit.osci.io \
--to=gerrit@gnutoolchain-gerrit.osci.io \
--cc=gdb-patches@sourceware.org \
--cc=scott@scottlinder.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox