From: Kevin Buettner <kevinb@redhat.com>
To: Ronald Hecht <ronald.hecht@gmx.de>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH] gdb: z80: Fix endless backtrace loop and assertion crashes
Date: Sat, 6 Jun 2026 12:40:38 -0700 [thread overview]
Message-ID: <20260606124038.110fa3b3@f42-zbm-amd> (raw)
In-Reply-To: <20260605185647.47976-1-ronald.hecht@gmx.de>
Hi Ronald,
On Fri, 5 Jun 2026 20:56:47 +0200
Ronald Hecht <ronald.hecht@gmx.de> wrote:
> This patch fixes two distinct issues in the Z80 frame unwind cache:
>
> 1. An infinite loop in the stack pointer wrapping logic. The `for (;;
> ++sp)` loop could run endlessly if the overflow condition `sp <
> this_base` was never met due to 16-bit address space wrapping. Introduced
> a `loop_count` to break out after 4 iterations as a sensible heuristic
> for Z80.
>
> 2. A potential internal GDB assertion failure. The code previously called
> `.addr()` directly on saved registers without verifying if they
> actually held an address, causing crashes when encountering unexpected
> register states (e.g. REG_UNKNOWN). Added a check for `.is_addr()`
> beforehand.
>
> gdb/ChangeLog:
> * z80-tdep.c (z80_frame_unwind_cache): Prevent infinite loop by
> adding loop_count. Check is_addr() before calling addr().
> ---
> gdb/z80-tdep.c | 14 ++++++++++----
> 1 file changed, 10 insertions(+), 4 deletions(-)
>
> diff --git a/gdb/z80-tdep.c b/gdb/z80-tdep.c
> index 3a0d5f7e393..5e1c3a877b3 100644
> --- a/gdb/z80-tdep.c
> +++ b/gdb/z80-tdep.c
> @@ -597,6 +597,7 @@ z80_frame_unwind_cache (const frame_info_ptr
> &this_frame, CORE_ADDR sp;
> CORE_ADDR sp_mask = (1 << gdbarch_ptr_bit(gdbarch)) - 1;
> enum bfd_endian byte_order = gdbarch_byte_order (gdbarch);
> + int loop_count = 0;
> /* Assume that the FP is this frame's SP but with that pushed
> stack space added back. */
> this_base = get_frame_register_unsigned (this_frame,
> Z80_SP_REGNUM); @@ -604,7 +605,7 @@ z80_frame_unwind_cache (const
> frame_info_ptr &this_frame, for (;; ++sp)
> {
> sp &= sp_mask;
> - if (sp < this_base)
> + if (++loop_count > 4 || sp < this_base)
I'm wondering if there's a better way to handle this? It seems to me
that we should be able come up with a comparison against the unmasked
'sp' value which detects bottom of stack (or end of address space). I
think that perhaps this might work:
...
for (;; ++sp)
{
if (sp > sp_mask)
{ /* overflow, looks like end of stack */
sp = this_base + info->size;
break;
}
/* find return address */
read_memory (sp, buf, addr_len);
...
Note that I got rid of the masking operation; It's no longer needed with
that 'sp > sp_mask' test. But you might want to rename 'sp_mask' to
be 'addr_space_max' or some such.
Can you test this version?
It may still be desirable to place a limit on the number of stack
slots that are checked in this code. I have no objection to doing
this. I only ask that you document the constant chosen ('4' perhaps)
and that you explain why it's likely enough for the z80 architecture.
(Put the explanation in a code comment, instead of only the commit
log.)
Kevin
next prev parent reply other threads:[~2026-06-06 19:41 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-05 18:56 Ronald Hecht
2026-06-06 19:40 ` Kevin Buettner [this message]
2026-06-07 7:36 ` Ronald Hecht
2026-06-07 7:48 ` [PATCH v2] " Ronald Hecht
2026-06-14 22:06 ` Kevin Buettner
2026-06-15 6:49 ` Ronald Hecht
2026-06-15 7:04 ` [PATCH v3] gdb: z80: Fix endless loop in frame unwinder and validate saved register types Ronald Hecht
2026-06-20 20:11 ` Kevin Buettner
2026-06-23 7:16 ` Ronald Hecht
2026-07-09 3:52 ` Kevin Buettner
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=20260606124038.110fa3b3@f42-zbm-amd \
--to=kevinb@redhat.com \
--cc=gdb-patches@sourceware.org \
--cc=ronald.hecht@gmx.de \
/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