From: Pedro Alves <palves@redhat.com>
To: Markus Metzger <markus.t.metzger@intel.com>
Cc: jan.kratochvil@redhat.com, gdb-patches@sourceware.org
Subject: Re: [patch v8 05/24] frame: artificial frame id's
Date: Thu, 12 Dec 2013 19:39:00 -0000 [thread overview]
Message-ID: <52AA10DD.2020506@redhat.com> (raw)
In-Reply-To: <1386839747-8860-6-git-send-email-markus.t.metzger@intel.com>
On 12/12/2013 09:15 AM, Markus Metzger wrote:
> At the moment, a frame must have a stack - except for the outer frame.
>
> When we analyze the recorded execution for "record btrace" to detect
> function calls and compute a back trace at some point in the recorded
> execution history, we will end up with frames without a stack.
To be more precise, the frames do have a stack, but it's <unavailable>.
I.e., it existed, but we didn't capture it, so we can't retrieve it.
I presume "p $sp" etc. will show <unavailable>, right?
>
> To prepare for this, support frame_id's without a stack component.
So special_addr will be a made up number, right? Will each such
frame have its own special_addr ?
> CC: Pedro Alves <palves@redhat.com>
>
> 2013-12-12 Markus Metzger <markus.t.metzger@intel.com>
>
> * frame.h (frame_id_build_artificial): New.
> * frame.c (frame_id_build_artificial): New.
> (frame_id_p): An artificial frame is valid.
> (frame_id_eq): A frame is equal to itself.
>
>
> ---
> gdb/frame.c | 30 +++++++++++++++++++++++-------
> gdb/frame.h | 6 ++++++
> 2 files changed, 29 insertions(+), 7 deletions(-)
>
> diff --git a/gdb/frame.c b/gdb/frame.c
> index ddd5e70..37d780e 100644
> --- a/gdb/frame.c
> +++ b/gdb/frame.c
> @@ -526,6 +526,21 @@ frame_id_build_wild (CORE_ADDR stack_addr)
> return id;
> }
>
> +/* See frame.h. */
> +
> +struct frame_id
> +frame_id_build_artificial (CORE_ADDR code_addr,
> + CORE_ADDR special_addr)
> +{
> + struct frame_id id = null_frame_id;
> +
> + id.code_addr = code_addr;
> + id.code_addr_p = 1;
> + id.special_addr = special_addr;
> + id.special_addr_p = 1;
> + return id;
> +}
> +
> int
> frame_id_p (struct frame_id l)
> {
> @@ -536,6 +551,9 @@ frame_id_p (struct frame_id l)
> /* outer_frame_id is also valid. */
> if (!p && memcmp (&l, &outer_frame_id, sizeof (l)) == 0)
> p = 1;
> + /* An artificial frame is also valid. */
> + if (!p && l.code_addr_p && l.special_addr_p)
> + p = 1;
> if (frame_debug)
> {
> fprintf_unfiltered (gdb_stdlog, "{ frame_id_p (l=");
> @@ -559,13 +577,11 @@ frame_id_eq (struct frame_id l, struct frame_id r)
> {
> int eq;
>
> - if (!l.stack_addr_p && l.special_addr_p
> - && !r.stack_addr_p && 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
> - we might step into another function - from which we can't
> - unwind either. More thought required to get rid of
> - outer_frame_id. */
> + if (memcmp (&l, &r, sizeof (l)) == 0)
> + /* Every frame is equal to itself.
> + 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;
> else if (!l.stack_addr_p || !r.stack_addr_p)
> /* Like a NaN, if either ID is invalid, the result is false.
Looks like frame_ id_eq (null_frame_id, null_frame_id) now
returns true, while it returns false before. If you discussed
all this and came to the conclusion it's OK, please document
it in the commit log. In any case (I'm not sure offhand if
that's OK), the NaN comment above is no longer correct,
and neither is this one:
/* Make the sentinel frame's ID valid, but invalid. That way all
comparisons with it should fail. */
frame->this_id.p = 1;
frame->this_id.value = null_frame_id;
> diff --git a/gdb/frame.h b/gdb/frame.h
> index e4e6b25..71f07dd 100644
> --- a/gdb/frame.h
> +++ b/gdb/frame.h
> @@ -174,6 +174,12 @@ extern struct frame_id frame_id_build_special (CORE_ADDR stack_addr,
> as the special identifier address are set to indicate wild cards. */
> extern struct frame_id frame_id_build_wild (CORE_ADDR stack_addr);
>
> +/* Construct an artificial frame ID. The first parameter is the frame's
> + constant code address (typically the function entry point), and the
> + second the frame's special identifier address. */
> +extern struct frame_id frame_id_build_artificial (CORE_ADDR code_addr,
> + CORE_ADDR special_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. */
>
--
Pedro Alves
next prev parent reply other threads:[~2013-12-12 19:39 UTC|newest]
Thread overview: 73+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-12-12 9:15 [patch v8 00/24] record-btrace: reverse Markus Metzger
2013-12-12 9:15 ` [patch v8 03/24] gdbarch: add instruction predicate methods Markus Metzger
2013-12-12 9:15 ` [patch v8 01/24] btrace, linux: fix memory leak when reading branch trace Markus Metzger
2013-12-12 9:15 ` [patch v8 16/24] record-btrace, frame: supply target-specific unwinder Markus Metzger
2013-12-12 9:15 ` [patch v8 14/24] record-btrace: supply register target methods Markus Metzger
2013-12-12 9:16 ` [patch v8 05/24] frame: artificial frame id's Markus Metzger
2013-12-12 19:39 ` Pedro Alves [this message]
2013-12-12 19:55 ` Jan Kratochvil
2013-12-13 8:04 ` Metzger, Markus T
2013-12-13 11:27 ` Jan Kratochvil
2013-12-13 11:42 ` Metzger, Markus T
2013-12-13 12:09 ` Pedro Alves
2013-12-13 13:01 ` Metzger, Markus T
2013-12-13 15:44 ` Pedro Alves
2013-12-13 17:51 ` Pedro Alves
2013-12-18 13:30 ` Metzger, Markus T
2013-12-12 9:16 ` [patch v8 23/24] record-btrace: show trace from enable location Markus Metzger
2013-12-13 19:50 ` Pedro Alves
2013-12-16 12:57 ` Metzger, Markus T
2013-12-16 19:41 ` Pedro Alves
2013-12-17 13:20 ` Metzger, Markus T
2013-12-17 16:59 ` Pedro Alves
2013-12-12 9:16 ` [patch v8 20/24] record-btrace: add record goto target methods Markus Metzger
2013-12-12 9:16 ` [patch v8 21/24] record-btrace: extend unwinder Markus Metzger
2013-12-13 19:45 ` Pedro Alves
2013-12-16 12:42 ` Metzger, Markus T
2013-12-16 19:22 ` Pedro Alves
2013-12-17 12:56 ` Metzger, Markus T
2013-12-12 9:16 ` [patch v8 24/24] record-btrace: add (reverse-)stepping support Markus Metzger
2013-12-12 16:36 ` Eli Zaretskii
2013-12-13 19:22 ` Pedro Alves
2013-12-16 15:56 ` Metzger, Markus T
2013-12-16 20:30 ` Pedro Alves
2013-12-17 14:14 ` Metzger, Markus T
2013-12-17 15:07 ` Metzger, Markus T
2013-12-17 15:48 ` Metzger, Markus T
2013-12-17 20:41 ` Pedro Alves
2013-12-17 20:34 ` Pedro Alves
2013-12-17 20:07 ` Pedro Alves
2013-12-18 9:44 ` Metzger, Markus T
2013-12-12 9:16 ` [patch v8 02/24] btrace: uppercase btrace_read_type Markus Metzger
2013-12-12 9:16 ` [patch v8 06/24] btrace: change branch trace data structure Markus Metzger
2013-12-12 9:16 ` [patch v8 12/24] btrace: add replay position to btrace thread info Markus Metzger
2013-12-12 9:16 ` [patch v8 09/24] btrace: increase buffer size Markus Metzger
2013-12-12 9:16 ` [patch v8 19/24] record-btrace: provide target_find_new_threads method Markus Metzger
2013-12-12 9:16 ` [patch v8 07/24] record-btrace: fix insn range in function call history Markus Metzger
2013-12-12 9:16 ` [patch v8 08/24] record-btrace: start counting at one Markus Metzger
2013-12-12 9:16 ` [patch v8 18/24] record-btrace: add to_wait and to_resume target methods Markus Metzger
2013-12-12 9:16 ` [patch v8 15/24] frame, backtrace: allow targets to supply a frame unwinder Markus Metzger
2013-12-13 18:27 ` Pedro Alves
2013-12-16 9:18 ` Metzger, Markus T
2013-12-16 19:02 ` Pedro Alves
2013-12-17 8:26 ` Metzger, Markus T
2013-12-17 9:48 ` Pedro Alves
2013-12-12 9:16 ` [patch v8 17/24] record-btrace: provide xfer_partial target method Markus Metzger
2013-12-13 18:43 ` Pedro Alves
2013-12-16 10:53 ` Metzger, Markus T
2013-12-16 19:16 ` Pedro Alves
2013-12-17 11:58 ` Metzger, Markus T
2013-12-17 16:56 ` Pedro Alves
2013-12-18 9:26 ` Metzger, Markus T
2013-12-18 10:39 ` Pedro Alves
2013-12-12 9:16 ` [patch v8 13/24] target: add ops parameter to to_prepare_to_store method Markus Metzger
2013-12-12 9:16 ` [patch v8 04/24] frame: add frame_is_tailcall function Markus Metzger
2013-12-12 9:16 ` [patch v8 10/24] record-btrace: optionally indent function call history Markus Metzger
2013-12-12 9:16 ` [patch v8 22/24] btrace, gdbserver: read branch trace incrementally Markus Metzger
2013-12-13 19:46 ` Pedro Alves
2013-12-16 12:47 ` Metzger, Markus T
2013-12-16 19:23 ` Pedro Alves
2013-12-12 9:16 ` [patch v8 11/24] record-btrace: make ranges include begin and end Markus Metzger
2013-12-13 17:56 ` Pedro Alves
2013-12-12 14:07 ` [patch v8 00/24] record-btrace: reverse Jan Kratochvil
2013-12-12 14:19 ` Metzger, Markus T
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=52AA10DD.2020506@redhat.com \
--to=palves@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=jan.kratochvil@redhat.com \
--cc=markus.t.metzger@intel.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