Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Andy Wingo <wingo@igalia.com>
To: Alexander Smundak <asmundak@google.com>
Cc: Phil Muldoon <pmuldoon@redhat.com>,  Doug Evans <dje@google.com>,
	 gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [RFC] [PATCH] Provide the ability to write the frame unwinder in Python
Date: Mon, 09 Mar 2015 09:42:00 -0000	[thread overview]
Message-ID: <8761aatsl5.fsf@igalia.com> (raw)
In-Reply-To: <CAHQ51u6UZ7A47rpGgX0QGeYSTCz1eo_3jWHc=q2ZX3YhqcJ6iQ@mail.gmail.com>	(Alexander Smundak's message of "Mon, 2 Mar 2015 14:56:00 -0800")

Greets Alexander,

One thing I found in your docs:

> +@subheading Returning Previous Frame
> +
> +If sniffer's @code{__call__} method recognizes the frame, it should
> +return a (@var{registers}, @var{frame_id_register_numbers}) tuple.
> +
> +@var{registers} describe the registers that can be unwound (i.e., the
> +registers from the previous frame that have been saved in the current
> +frame described by @var{sniffer_info}). It is a tuple where each
> +element is a (@var{regnum}, @var{regdata}) 2-tuple.  @var{regnum} is
> +a register number, and @var{regdata} is register contents (a
> +@code{gdb.Value} object).
> +
> +@var{frame_id_register_numbers} is a tuple specifying the registers
> +used to construct frame ID of the returned frame.  It is a (@var{sp}),
> +(@var{sp}, @var{pc}) or (@var{sp}, @var{pc}, @var{special}) tuple,
> +where @var{sp}, @var{pc}, @var{special} are register numbers. The
> +referenced registers should be present in @var{registers} tuple. The
> +frame ID is constructed by calling
> +@code{frame_id_build_wild}(@var{value}(@var{sp})),
> +@code{frame_id_build}(@var{value}(@var{sp}), @var{value}(@var{pc})),
> +or @code{frame_id_build}(@var{value}(@var{sp}), @var{value}(@var{pc}),
> +@var{value}(@var{special})) respectively.

The frame_id that the unwinder computes is for THIS, not for PREVIOUS,
so the interface is incorrect if it works as documented.

Here is a section of the docs that I wrote for the Guile side.

   Before getting into the API, we should discuss how unwinders work in
   @value{GDBN}.

   As an example, consider a stack in which we have already computed
   frame 0 and we want to compute frame 1.  We say that frame 0 is the
   ``inner'' frame, and frame 1 will be the ``outer'' frame.

   Unwinding starts with a model of the state of all registers in an
   inner, already unwound frame.  In our case, we start with frame 0.
   @value{GDBN} then constructs a ephemeral frame object for the outer
   frame that is being built (frame 1) and links it to the inner frame
   (frame 0).  @value{GDBN} then goes through its list of registered
   unwinders, searching for one that knows how to unwind the frame.  When
   it finds one, @value{GDBN} will ask the unwinder to compute a frame
   identifier for the outer frame.  Once the unwinder has done so, the
   frame is marked as ``valid'' and can be accessed using the normal
   frame API.

   A frame identifier (frame ID) consists of code and data pointers
   associated with a frame which will remain valid as long as the frame
   is still alive.  Usually a frame ID is a pair of the code and stack
   pointers as they were when control entered the function associated
   with the frame, though as described below there are other ways to
   build a frame ID@.  However as you can see, computing the frame ID
   requires some input from the unwinder to determine the start code
   address (PC) and the frame pointer (FP), especially on platforms that
   don't dedicate a register to the FP.

   (Given this description, you might wonder how the frame ID for the
   innermost frame (frame 0) is unwound, given that unwinding requires an
   inner frame.  The answer is that internally, @value{GDBN} always has a
   ``sentinel'' frame that is inner to the innermost frame, and which has
   a pre-computed unwinder that just returns the registers as they are,
   without unwinding.)

   The Guile frame unwinder API loosely follows this protocol as
   described above.  Guile will build a special ``ephemeral frame
   object'' corresponding the frame being unwound (in our example,
   frame 1).  It allows the user to read registers from that ephemeral
   frame, which in reality are unwound from the already-existing frame
   0.  If the unwinder decides that it can handle the frame in question,
   it then sets the frame ID on the ephemeral frame.  It also records the
   values of any registers saved in the frame, for use when unwinding
   its outer frame (frame 2).

Regards,

Andy


  parent reply	other threads:[~2015-03-09  9:42 UTC|newest]

Thread overview: 60+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-12-15 18:14 Alexander Smundak
2014-12-22 19:24 ` Alexander Smundak
2014-12-29 18:02   ` Alexander Smundak
2015-01-05 17:53     ` Alexander Smundak
2015-01-12 20:03       ` Alexander Smundak
2015-01-22  3:31         ` Alexander Smundak
2015-01-29  1:36           ` Alexander Smundak
2015-01-12 21:00 ` Simon Marchi
2015-01-12 21:22   ` Doug Evans
2015-02-04 22:36 ` Doug Evans
2015-02-12 17:58   ` Alexander Smundak
2015-02-19  2:32     ` Alexander Smundak
2015-02-20 11:12     ` Phil Muldoon
2015-02-26  3:09       ` Alexander Smundak
2015-03-02 22:56         ` Alexander Smundak
2015-03-03  8:46           ` Andy Wingo
2015-03-04  2:36             ` Alexander Smundak
2015-03-04  7:49               ` Andy Wingo
2015-03-09 11:02                 ` Phil Muldoon
2015-03-11  2:22                   ` Alexander Smundak
2015-03-11  8:49                     ` Andy Wingo
2015-03-11 17:34                       ` Doug Evans
2015-03-11 18:48                       ` Alexander Smundak
2015-03-16 11:29                         ` Andy Wingo
2015-03-16 12:01                           ` Andy Wingo
2015-03-16 17:25                           ` Alexander Smundak
2015-03-17  8:57                             ` Andy Wingo
2015-03-17 19:48                               ` Alexander Smundak
2015-03-17 21:37                                 ` Alexander Smundak
2015-03-18  8:54                                   ` Andy Wingo
2015-03-18 22:57                                     ` Alexander Smundak
2015-03-23 19:58                                       ` Doug Evans
2015-03-24  9:06                                         ` Andy Wingo
2015-03-26  3:31                                         ` Alexander Smundak
2015-03-26 18:53                                           ` Eli Zaretskii
2015-03-27 22:29                                           ` Doug Evans
2015-03-28  1:10                                             ` Alexander Smundak
2015-03-30 17:45                                               ` Doug Evans
2015-03-30 19:49                                                 ` Alexander Smundak
2015-03-31 22:36                                                   ` Doug Evans
2015-04-01  0:09                                                     ` Alexander Smundak
2015-04-01  0:28                                                       ` Doug Evans
2015-03-18 23:25                                 ` Doug Evans
2015-03-19  0:36                                   ` Alexander Smundak
2015-03-19  8:12                                     ` Andy Wingo
2015-03-20  0:15                                       ` Doug Evans
2015-03-20  2:27                                         ` Alexander Smundak
2015-03-20 17:48                                           ` Doug Evans
2015-03-20  8:26                                         ` Andy Wingo
2015-03-20 18:32                                           ` Doug Evans
2015-03-17 22:21                               ` Doug Evans
2015-03-18  8:57                                 ` Andy Wingo
2015-03-18 16:48                                   ` Doug Evans
2015-03-19  8:04                                     ` Andy Wingo
2015-03-09  9:42           ` Andy Wingo [this message]
2015-03-03  0:49         ` Alexander Smundak
2015-03-03 14:38           ` Andy Wingo
2015-03-04  2:52             ` Alexander Smundak
2015-02-20  9:42 ` Phil Muldoon
2015-02-20  9:59   ` Phil Muldoon

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=8761aatsl5.fsf@igalia.com \
    --to=wingo@igalia.com \
    --cc=asmundak@google.com \
    --cc=dje@google.com \
    --cc=gdb-patches@sourceware.org \
    --cc=pmuldoon@redhat.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