Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: "Metzger, Markus T" <markus.t.metzger@intel.com>
To: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: "gdb-patches@sourceware.org" <gdb-patches@sourceware.org>
Subject: RE: [patch v6 18/21] record-btrace: extend unwinder
Date: Wed, 06 Nov 2013 13:45:00 -0000	[thread overview]
Message-ID: <A78C989F6D9628469189715575E55B230AA119C4@IRSMSX104.ger.corp.intel.com> (raw)
In-Reply-To: <20131006194943.GD28020@host2.jankratochvil.net>

> -----Original Message-----
> From: gdb-patches-owner@sourceware.org [mailto:gdb-patches-
> owner@sourceware.org] On Behalf Of Jan Kratochvil
> Sent: Sunday, October 06, 2013 9:50 PM

Hello Jan,

Thanks for your feedback.  I've been busy otherwise the last few weeks;
now I'm switching back to the btrace series.


> > +  while (bfun->segment.prev != NULL)
> > +    bfun = bfun->segment.prev;
> > +
> > +  stack = 0;
> 
> As discussed elsewhere I do not find correct to set stack_p = 1 && stack = 0.
> I think frame_id_p() can return true even if special_p == 1 but stack_p == 0.
> You sure need some new function similar to frame_id_build_special().

Besides frame_id_p I also had to change frame_id_eq.  Here's how it look
like.  Are you OK with such changes?  Should I put the frame.[hc] changes into
a separate patch, as well?

I had to make the first test in frame_id_eq stricter than it was since
otherwise all artificial frames would have been equal to each other.
I ran the full test suite without regressions (native on 64bit IA FC19), but I'm
Not exactly sure what has been tested.  The report lists 34 untested and 133
unsupported for both runs.


diff --git a/gdb/frame.c b/gdb/frame.c
index 3157167..e8dd029 100644
--- a/gdb/frame.c
+++ b/gdb/frame.c
@@ -491,6 +491,19 @@ frame_id_build_wild (CORE_ADDR stack_addr)
   return id;
 }
 
+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)
 {
@@ -501,6 +514,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=");
@@ -524,13 +540,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.
diff --git a/gdb/frame.h b/gdb/frame.h
index 7109dbc..9fd278c 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 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.  */
diff --git a/gdb/record-btrace.c b/gdb/record-btrace.c
index 02b5e3d..63f09c6 100644
--- a/gdb/record-btrace.c
+++ b/gdb/record-btrace.c
@@ -1036,7 +1036,7 @@ record_btrace_frame_this_id (struct frame_info *this_frame, void **this_cache,
 {
   const struct btrace_frame_cache *cache;
   const struct btrace_function *bfun;
-  CORE_ADDR stack, code, special;
+  CORE_ADDR code, special;
 
   cache = *this_cache;
 
@@ -1046,11 +1046,10 @@ record_btrace_frame_this_id (struct frame_info *this_frame, void **this_cache,
   while (bfun->segment.prev != NULL)
     bfun = bfun->segment.prev;
 
-  stack = 0;
   code = get_frame_func (this_frame);
   special = bfun->number;
 
-  *this_id = frame_id_build_special (stack, code, special);
+  *this_id = frame_id_build_artificial (code, special);
 
   DEBUG ("[frame] %s id: (!stack, pc=%s, special=%s)",
 	 btrace_get_bfun_name (cache->bfun),


> > +  code = get_frame_func (this_frame);
> > +  special = (CORE_ADDR) bfun;
> 
> This is not safe, GDB host may be 64-bit and target 32-bit and in such case
> without --enable-64-bit-bfd there will be sizeof (CORE_ADDR) == 4,
> therefore different BFUNs may get the same SPECIAL.
> bfun->insn_offset or bfun->insn_offset should serve better I think.

I changed this to use bfun->number, instead.


> Also there could be a comment like (it still applies if one uses any of bfun,
> bfun->insn_offset or bfun->insn_offset):
>   /* The btrace_function structures can be rebuilt but only after inferior has
>      run.  In such case all btrace frame have been deleted and there remain no
>      stale uses of BFUN addresses.  */

Doesn't gdb keep frame id's alive during stepping?  I thought they were used
to detect steps into subroutines.

We could end up with the same frame id but a different frame if we
recomputed the entire trace (i.e. the trace buffer overflows and we can't
stitch traces) and we happened to have the same function at the same
position in the trace.

But this might also happen for all other frame id's.


Regards,
Markus.

Intel GmbH
Dornacher Strasse 1
85622 Feldkirchen/Muenchen, Deutschland
Sitz der Gesellschaft: Feldkirchen bei Muenchen
Geschaeftsfuehrer: Christian Lamprechter, Hannes Schwaderer, Douglas Lusk
Registergericht: Muenchen HRB 47456
Ust.-IdNr./VAT Registration No.: DE129385895
Citibank Frankfurt a.M. (BLZ 502 109 00) 600119052


  reply	other threads:[~2013-11-06 13:03 UTC|newest]

Thread overview: 41+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-09-20 11:30 [patch v6 00/21] record-btrace: reverse Markus Metzger
2013-09-20 11:30 ` [patch v6 06/21] btrace: increase buffer size Markus Metzger
2013-09-20 11:30 ` [patch v6 15/21] record-btrace: add to_wait and to_resume target methods Markus Metzger
2013-09-20 11:30 ` [patch v6 14/21] record-btrace: provide xfer_partial target method Markus Metzger
2013-09-20 11:30 ` [patch v6 02/21] gdbarch: add instruction predicate methods Markus Metzger
2013-09-20 11:30 ` [patch v6 12/21] frame, backtrace: allow targets to supply a frame unwinder Markus Metzger
2013-09-20 11:30 ` [patch v6 10/21] target: add ops parameter to to_prepare_to_store method Markus Metzger
2013-09-20 11:30 ` [patch v6 16/21] record-btrace: provide target_find_new_threads method Markus Metzger
2013-09-20 11:31 ` [patch v6 13/21] record-btrace, frame: supply target-specific unwinder Markus Metzger
2013-09-20 11:31 ` [patch v6 19/21] btrace, gdbserver: read branch trace incrementally Markus Metzger
2013-10-06 19:51   ` Jan Kratochvil
2013-09-20 11:31 ` [patch v6 05/21] record-btrace: start counting at one Markus Metzger
2013-09-20 11:31 ` [patch v6 04/21] record-btrace: fix insn range in function call history Markus Metzger
2013-09-20 11:31 ` [patch v6 08/21] record-btrace: make ranges include begin and end Markus Metzger
2013-09-20 11:31 ` [patch v6 07/21] record-btrace: optionally indent function call history Markus Metzger
2013-10-06 19:47   ` Jan Kratochvil
2013-09-20 11:31 ` [patch v6 01/21] btrace, linux: fix memory leak when reading branch trace Markus Metzger
2013-09-20 11:31 ` [patch v6 03/21] btrace: change branch trace data structure Markus Metzger
2013-10-06 19:46   ` Jan Kratochvil
2013-09-20 11:31 ` [patch v6 18/21] record-btrace: extend unwinder Markus Metzger
2013-10-06 19:49   ` Jan Kratochvil
2013-11-06 13:45     ` Metzger, Markus T [this message]
2013-11-25 21:11       ` Jan Kratochvil
2013-09-20 11:31 ` [patch v6 09/21] btrace: add replay position to btrace thread info Markus Metzger
2013-09-20 11:31 ` [patch v6 17/21] record-btrace: add record goto target methods Markus Metzger
2013-10-06 19:48   ` Jan Kratochvil
2013-09-20 11:31 ` [patch v6 20/21] record-btrace: show trace from enable location Markus Metzger
2013-09-20 11:31 ` [patch v6 21/21] record-btrace: add (reverse-)stepping support Markus Metzger
2013-10-06 19:52   ` Jan Kratochvil
2013-11-06 15:06     ` Metzger, Markus T
2013-11-26 13:48       ` Jan Kratochvil
2013-09-20 11:31 ` [patch v6 11/21] record-btrace: supply register target methods Markus Metzger
2013-09-26 19:16 ` v6 crash bugreport [Re: [patch v6 00/21] record-btrace: reverse] Jan Kratochvil
2013-09-27  6:37   ` Metzger, Markus T
2013-10-06 19:59 ` [+rfc] Re: [patch v6 00/21] record-btrace: reverse Jan Kratochvil
2013-11-07 15:44   ` Metzger, Markus T
2013-11-27 20:35     ` Jan Kratochvil
2013-11-28 10:54       ` Metzger, Markus T
2013-11-28 22:35         ` Jan Kratochvil
2013-11-29 14:27           ` Metzger, Markus T
2013-12-11 19:57             ` Jan Kratochvil

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=A78C989F6D9628469189715575E55B230AA119C4@IRSMSX104.ger.corp.intel.com \
    --to=markus.t.metzger@intel.com \
    --cc=gdb-patches@sourceware.org \
    --cc=jan.kratochvil@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