From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id IOKIAarlBGPmDywAWB0awg (envelope-from ) for ; Tue, 23 Aug 2022 10:35:22 -0400 Received: by simark.ca (Postfix, from userid 112) id 047F81E4A7; Tue, 23 Aug 2022 10:35:22 -0400 (EDT) Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=gNkg+AtK; dkim-atps=neutral X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI,URIBL_BLOCKED autolearn=ham autolearn_force=no version=3.4.6 Received: from sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 73A131E13B for ; Tue, 23 Aug 2022 10:35:21 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1279D3858287 for ; Tue, 23 Aug 2022 14:35:21 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1279D3858287 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1661265321; bh=8Kaam5u++86T3NzzfbtV+ri7uBjkZebvp6ihjAtVL8w=; h=To:Subject:Date:In-Reply-To:References:List-Id:List-Unsubscribe: List-Archive:List-Post:List-Help:List-Subscribe:From:Reply-To:Cc: From; b=gNkg+AtKUh8He0RmZBHG3DitHZzC1xWMhwVkZox9oBBZwTKEZS6Hl/80hA85KQO+4 33/6S+oDr5nia9xOtCe88a1Qgb6D8nGd0D4ST8QYWR5bFNTkK++cHMaTuaJCHIMXNf TCS+x187EM04NhOK2KhtzUWv3q8brGjsOJsuk0CI= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.129.124]) by sourceware.org (Postfix) with ESMTPS id A7C003857BB3 for ; Tue, 23 Aug 2022 14:35:02 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org A7C003857BB3 Received: from mimecast-mx02.redhat.com (mx3-rdu2.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-171-yt7AUZqSOBuT1eWHx-iEjA-1; Tue, 23 Aug 2022 10:34:59 -0400 X-MC-Unique: yt7AUZqSOBuT1eWHx-iEjA-1 Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.rdu2.redhat.com [10.11.54.3]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id BD2ED1C0BC6A; Tue, 23 Aug 2022 14:34:58 +0000 (UTC) Received: from fedora.redhat.com (unknown [10.40.194.157]) by smtp.corp.redhat.com (Postfix) with ESMTPS id E4B6B1121314; Tue, 23 Aug 2022 14:34:57 +0000 (UTC) To: gdb-patches@sourceware.org Subject: [PATCH v2 1/2] Change calculation of frame_id by amd64 epilogue unwinder Date: Tue, 23 Aug 2022 16:22:04 +0200 Message-Id: <20220823142204.31659-2-blarsen@redhat.com> In-Reply-To: <20220823142204.31659-1-blarsen@redhat.com> References: <20220823142204.31659-1-blarsen@redhat.com> MIME-Version: 1.0 X-Scanned-By: MIMEDefang 2.78 on 10.11.54.3 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Transfer-Encoding: 8bit Content-Type: text/plain; charset="US-ASCII"; x-default=true X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Bruno Larsen via Gdb-patches Reply-To: Bruno Larsen Cc: pedro@palves.net Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" 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