From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id gPcROdl3JGozyzgAWB0awg (envelope-from ) for ; Sat, 06 Jun 2026 15:41:13 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=GP+RXGsY; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id D7B941E0A6; Sat, 06 Jun 2026 15:41:13 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-3.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIMWL_WL_HIGH,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 3209E1E062 for ; Sat, 06 Jun 2026 15:41:12 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id A8B144C31828 for ; Sat, 6 Jun 2026 19:41:11 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A8B144C31828 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=GP+RXGsY Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTP id 5C1454B1A37A for ; Sat, 6 Jun 2026 19:40:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 5C1454B1A37A Authentication-Results: sourceware.org; dmarc=pass (p=quarantine dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 5C1454B1A37A Authentication-Results: sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1780774846; cv=none; b=uL1BaBaVNYPi/aCfaCrBvLJL3ZHturFUa0YMNkZSt9w+kzd9HXtBaAxTyGY8ziK3RxQKqkJ9glsJtGZeP9aE54ji6VQT0SMaR4yxGKdW4UUA/cqNEHXUx3M64yzg4RwcGlo0mA3A/kfDs6iCLRczzbYc1TWBDe7GHhzkloVhSfU= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1780774846; c=relaxed/simple; bh=z+mb8ynbJZq5cD0gAFsHY61zeTnFu3gfizc1eUFVI3Q=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=AqY0mVlQJUyxBk/R3KFpVp3+LvVONZhB/Byl9/nmsSFvhAIZIroGeGqf0qlVuGDMcSu1nxccMNXHGQLk4OaQGjCMKEhX+rXlkhgrotq1ERI7Dsmx2ATeqPHRF6CQfj3IYb1vAVatEv3iq4ORScDqGVgkf2WGkwnMlAx+HOiWXR8= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=GP+RXGsY DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 5C1454B1A37A DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1780774845; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=QoRQaEOY4CXSO8huCoQTzzhNOxLKmA51Kpi5/qrVAtY=; b=GP+RXGsYYdcTXKRJjRXhkzSIdKNAjQsFkvpi5jDVfqi+ipLMB98J2gElc/sF3ILXViXadt V+RW/mSEmxdgBN9NiWZwTTFXBqoeQw4lGZ/Xzdv+Bkr9adkA6Txhch0D9+B891WCIdSrz6 +i13RBNSs1SD1E+zrO55Cng1U38sXaI= Received: from mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (ec2-35-165-154-97.us-west-2.compute.amazonaws.com [35.165.154.97]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-682-Jlj5qQ3wOvSaO5j9JQTdbg-1; Sat, 06 Jun 2026 15:40:42 -0400 X-MC-Unique: Jlj5qQ3wOvSaO5j9JQTdbg-1 X-Mimecast-MFC-AGG-ID: Jlj5qQ3wOvSaO5j9JQTdbg_1780774841 Received: from mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.17]) (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 mx-prod-mc-06.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 6532C180034C; Sat, 6 Jun 2026 19:40:41 +0000 (UTC) Received: from f42-zbm-amd (unknown [10.22.64.38]) by mx-prod-int-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 9DC121955F22; Sat, 6 Jun 2026 19:40:40 +0000 (UTC) Date: Sat, 6 Jun 2026 12:40:38 -0700 From: Kevin Buettner To: Ronald Hecht Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] gdb: z80: Fix endless backtrace loop and assertion crashes Message-ID: <20260606124038.110fa3b3@f42-zbm-amd> In-Reply-To: <20260605185647.47976-1-ronald.hecht@gmx.de> References: <20260605185647.47976-1-ronald.hecht@gmx.de> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.17 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: BV8qaNhNXWdOErSDZjyUv4qgZ0D7nckh-Gn79SRQl5E_1780774841 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org Hi Ronald, On Fri, 5 Jun 2026 20:56:47 +0200 Ronald Hecht 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