Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Bruno Larsen via Gdb-patches <gdb-patches@sourceware.org>
To: gdb-patches@sourceware.org
Cc: pedro@palves.net
Subject: [PATCH v2 1/2] Change calculation of frame_id by amd64 epilogue unwinder
Date: Tue, 23 Aug 2022 16:22:04 +0200	[thread overview]
Message-ID: <20220823142204.31659-2-blarsen@redhat.com> (raw)
In-Reply-To: <20220823142204.31659-1-blarsen@redhat.com>

When GDB is stopped at a ret instruction and no debug information is
available for unwinding, GDB defaults to the amd64 epilogue unwinder, to
be able to generate a decent backtrace. However, when calculating the
frame id, the epilogue unwinder generates information as if the return
instruction was the whole frame.

This was an issue especially when attempting to reverse debug, as GDB
would place a step_resume_breakpoint from the epilogue of a function if
we were to attempt to skip that function, and this breakpoint should
ideally have the current function's frame_id to avoid other problems
such as PR record/16678.

This commit changes the frame_id calculation for the amd64 epilogue,
so that it is always the same as the dwarf2 unwinder's frame_id.
---
 gdb/amd64-tdep.c | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/gdb/amd64-tdep.c b/gdb/amd64-tdep.c
index d89e06d27cb..17c82ac919c 100644
--- a/gdb/amd64-tdep.c
+++ b/gdb/amd64-tdep.c
@@ -2943,7 +2943,7 @@ amd64_epilogue_frame_cache (struct frame_info *this_frame, void **this_cache)
 					      byte_order) + cache->sp_offset;
 
       /* Cache pc will be the frame func.  */
-      cache->pc = get_frame_pc (this_frame);
+      cache->pc = get_frame_func (this_frame);
 
       /* The saved %esp will be at cache->base plus 16.  */
       cache->saved_sp = cache->base + 16;
@@ -2986,7 +2986,7 @@ amd64_epilogue_frame_this_id (struct frame_info *this_frame,
   if (!cache->base_p)
     (*this_id) = frame_id_build_unavailable_stack (cache->pc);
   else
-    (*this_id) = frame_id_build (cache->base + 8, cache->pc);
+    (*this_id) = frame_id_build (cache->saved_sp, cache->pc);
 }
 
 static const struct frame_unwind amd64_epilogue_frame_unwind =
-- 
2.37.2


  reply	other threads:[~2022-08-23 14:35 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-08-23 14:22 [PATCH v2 0/2] Fix reverse nexting over recursions Bruno Larsen via Gdb-patches
2022-08-23 14:22 ` Bruno Larsen via Gdb-patches [this message]
2022-08-24 13:11   ` [PATCH v2 1/2] Change calculation of frame_id by amd64 epilogue unwinder Andrew Burgess via Gdb-patches
2022-08-24 13:42     ` Andrew Burgess via Gdb-patches
2022-08-30 11:35     ` Bruno Larsen via Gdb-patches
2022-08-24 15:38   ` Andrew Burgess via Gdb-patches
2022-08-23 14:22 ` [PATCH v2 2/2] gdb/reverse: Fix stepping over recursive functions Bruno Larsen via Gdb-patches
2022-08-24 13:40   ` Andrew Burgess via Gdb-patches

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=20220823142204.31659-2-blarsen@redhat.com \
    --to=gdb-patches@sourceware.org \
    --cc=blarsen@redhat.com \
    --cc=pedro@palves.net \
    /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