public inbox for gdb-cvs@sourceware.org
help / color / mirror / Atom feed
From: Simon Marchi <simark@sourceware.org>
To: gdb-cvs@sourceware.org
Subject: [binutils-gdb] gdb: add user-created frames to stash
Date: Fri, 20 Jan 2023 19:52:47 +0000 (GMT)	[thread overview]
Message-ID: <20230120195247.624F83858D20@sourceware.org> (raw)

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=f649a718522b018bbb09eb96beb103a4f5892a45

commit f649a718522b018bbb09eb96beb103a4f5892a45
Author: Simon Marchi <simon.marchi@polymtl.ca>
Date:   Tue Dec 13 22:34:36 2022 -0500

    gdb: add user-created frames to stash
    
    A subsequent patch makes it possible for frame_info_ptr to reinflate
    user-created frames.  If two frame_info_ptr objects wrapping the same
    user-created frame_info need to do reinflation, we want them to end up
    pointing to the same frame_info instance, and not create two separate
    frame_infos.  Otherwise, GDB gets confused down the line, as the state
    kept in one frame_info object starts differing from the other
    frame_info.
    
    Achieve this by making create_new_frame place the user-created frames in
    the frame stash.  This way, when the second frame_info_ptr does
    reinflation, it will find the existing frame_info object, created by the
    other frame_info_ptr, in the frame stash.
    
    To make the frame stash differentiate between regular and user-created
    frame infos which would otherwise be equal, change frame_addr_hash and
    frame_id::operator== to account for frame_id::user_created_p.
    
    I made create_new_frame look up existing frames in the stash, and only
    create one if it doesn't find one.  The goal is to avoid the
    "select-frame view"/"info frame view"/"frame view" commands from
    overriding existing entries into the stash, should the user specify the
    same frame more than once.  This will also help in the subsequent patch
    that makes frame_info_ptr capable of reinflating user-created frames.
    It will be able to just call create_new_frame and it will do the right
    thing.
    
    Change-Id: I14ba5799012056c007b4992ecb5c7adafd0c2404
    Reviewed-By: Bruno Larsen <blarsen@redhat.com>

Diff:
---
 gdb/frame.c | 19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/gdb/frame.c b/gdb/frame.c
index 4dcfad37cd7..2e6a477ef16 100644
--- a/gdb/frame.c
+++ b/gdb/frame.c
@@ -240,6 +240,9 @@ frame_addr_hash (const void *ap)
     hash = iterative_hash (&f_id.special_addr,
 			   sizeof (f_id.special_addr), hash);
 
+  char user_created_p = f_id.user_created_p;
+  hash = iterative_hash (&user_created_p, sizeof (user_created_p), hash);
+
   return hash;
 }
 
@@ -775,6 +778,8 @@ frame_id::operator== (const frame_id &r) const
   else if (artificial_depth != r.artificial_depth)
     /* If artificial depths are different, the frames must be different.  */
     eq = false;
+  else if (user_created_p != r.user_created_p)
+    eq = false;
   else
     /* Frames are equal.  */
     eq = true;
@@ -1931,6 +1936,14 @@ create_new_frame (CORE_ADDR addr, CORE_ADDR pc)
 
   frame_debug_printf ("addr=%s, pc=%s", hex_string (addr), hex_string (pc));
 
+  /* Avoid creating duplicate frames, search for an existing frame with that id
+     in the stash.  */
+  frame_id id = frame_id_build (addr, pc);
+  id.user_created_p = 1;
+  frame_info_ptr frame = frame_stash_find (id);
+  if (frame != nullptr)
+    return frame;
+
   fi = FRAME_OBSTACK_ZALLOC (struct frame_info);
 
   fi->next = create_sentinel_frame (current_program_space,
@@ -1952,8 +1965,10 @@ create_new_frame (CORE_ADDR addr, CORE_ADDR pc)
   frame_unwind_find_by_frame (frame_info_ptr (fi), &fi->prologue_cache);
 
   fi->this_id.p = frame_id_status::COMPUTED;
-  fi->this_id.value = frame_id_build (addr, pc);
-  fi->this_id.value.user_created_p = 1;
+  fi->this_id.value = id;
+
+  bool added = frame_stash_add (fi);
+  gdb_assert (added);
 
   frame_debug_printf ("  -> %s", fi->to_string ().c_str ());

                 reply	other threads:[~2023-01-20 19:52 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20230120195247.624F83858D20@sourceware.org \
    --to=simark@sourceware.org \
    --cc=gdb-cvs@sourceware.org \
    /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;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).