From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id sq4dG/QlL2qVNAcAWB0awg (envelope-from ) for ; Sun, 14 Jun 2026 18:06:44 -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=bnyfXX9V; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 5B1C81E070; Sun, 14 Jun 2026 18:06:44 -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.1 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_SBL_CSS autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [IPv6:2620:52:6:3111::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 7867C1E070 for ; Sun, 14 Jun 2026 18:06:43 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id F164E4B920E7 for ; Sun, 14 Jun 2026 22:06:41 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org F164E4B920E7 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=bnyfXX9V 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 6B0A24BB58AC for ; Sun, 14 Jun 2026 22:06:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6B0A24BB58AC 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 6B0A24BB58AC 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=1781474776; cv=none; b=I/2x9/mEPlgPbtwsNJ7WKF/TkmRq6XvJOZ7iWjwhLCr7dxGREyEuGjKJzddDKmt46PMHCr8Kxnn69vSnPuwtMq4agitUyqP9rU00f76cwbUCx/Rf55r6LsGpFfbdT1BVibHH9nlI/CXBtXk1mm4JTdlRY3+XL/WJasHyj+kJEsc= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1781474776; c=relaxed/simple; bh=4BG2Esai+TvsN02mjUyw65jUUA8cPKZBxioEp6mL/CI=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=uyhM//2LmP/E/pD1HAupyLsbfSh250QDcVWT2+J+2CYkqIDmx7rvVk9qTVomTXvKeFJjCJEZxRz1gE0o6+gVnKzpR/KDxb76vvy3cKGta3FX4d8WPzpFUovj32cjAFdtOUvPGo5YRhb4WiftBSTSag5m3WCR7zVIlnDwOMH4q+Q= 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=bnyfXX9V DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6B0A24BB58AC DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1781474775; 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=wflJ63YMqc0iZY2EJc/JY/++akTDi5xDFhAP9piaYaE=; b=bnyfXX9VBAK+FnolxGfkNp7PtEGcFh3y9zjqw7QbWCDUR8FykrNHJczxdv0AHtjqxyQhsA Cf9GdaeqJU0kALDN1Bhdjv9P6gJPTHHa3ZqqD7s1A8B4SlzI1DUZncUGZC6wVlC+RbOvLh O9vLyFvCh65n/qNvCJ3uosKToShdcfQ= Received: from mx-prod-mc-05.mail-002.prod.us-west-2.aws.redhat.com (ec2-54-186-198-63.us-west-2.compute.amazonaws.com [54.186.198.63]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-408-tswCbQv6OUamWAGzVryZyQ-1; Sun, 14 Jun 2026 18:06:12 -0400 X-MC-Unique: tswCbQv6OUamWAGzVryZyQ-1 X-Mimecast-MFC-AGG-ID: tswCbQv6OUamWAGzVryZyQ_1781474771 Received: from mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.12]) (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-05.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 876CA1955F68; Sun, 14 Jun 2026 22:06:11 +0000 (UTC) Received: from f44-mesa-1 (unknown [10.22.80.31]) by mx-prod-int-03.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id B0F521955BC0; Sun, 14 Jun 2026 22:06:10 +0000 (UTC) Date: Sun, 14 Jun 2026 15:06:08 -0700 From: Kevin Buettner To: Ronald Hecht Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v2] gdb: z80: Fix endless backtrace loop and assertion crashes Message-ID: <20260614150230.2fd33d6e@f44-mesa-1> In-Reply-To: <20260607074801.32477-1-ronald.hecht@gmx.de> References: <20260606124038.110fa3b3@f42-zbm-amd> <20260607074801.32477-1-ronald.hecht@gmx.de> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.0 on 10.30.177.12 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: 4BXYedNkSIdO5gmbfm48ZVC1dI5YWrzuaNA3yXE8Gh4_1781474771 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, Just a few nits... On Sun, 7 Jun 2026 09:48:01 +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. This is fixed by > checking for `sp > addr_space_max` instead of masking the address. > Additionally, a `loop_count` is introduced to break out after 4 iterations. > This prevents severe slow-downs on remote targets caused by scanning > large portions of the address space when the stack is corrupt. > > 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 > checking addr_space_max and adding loop_count. Check is_addr() > before calling addr(). > --- > gdb/z80-tdep.c | 29 +++++++++++++++++++++++------ > 1 file changed, 23 insertions(+), 6 deletions(-) > > diff --git a/gdb/z80-tdep.c b/gdb/z80-tdep.c > index 3a0d5f7e393..832433f05cb 100644 > --- a/gdb/z80-tdep.c > +++ b/gdb/z80-tdep.c > @@ -595,16 +595,28 @@ z80_frame_unwind_cache (const frame_info_ptr &this_frame, > { > CORE_ADDR addr; > CORE_ADDR sp; > - CORE_ADDR sp_mask = (1 << gdbarch_ptr_bit(gdbarch)) - 1; > + CORE_ADDR addr_space_max = (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); > sp = this_base + info->size; > for (;; ++sp) > { > - sp &= sp_mask; > - if (sp < this_base) > + /* Limit the scan to 4 iterations. If the unwinder's frame > + size calculation is slightly off (e.g. due to unpopped > + 16-bit arguments or temporary pushes like SDCC sometimes > + generates), the return address might be hidden a few > + bytes deeper. Scanning up to 4 bytes comfortably covers > + one 32-bit or two 16-bit misplaced values. Scanning > + further (e.g. 8+ bytes) drastically increases the risk of > + false positives: we might wander into the caller's local > + variables, hit a random 0xCD (CALL) byte, and generate a > + corrupted backtrace. It also prevents massive slow-downs > + on remote serial targets if the stack is severely > + corrupted. */ There's a whitespace problem in the above comment. Our whitespace conventions use tabs in the place of (multiples of) 8 leading spaces. You've used spaces here with no tabs on the continuation lines. (The first line is correct.) Another coding convention nit: GNU coding conventions have two spaces following a period. Also, I believe that the CALL matching code also matches conditional call instructions, but you mention only the unconditional case. Not sure if it's worth changing the comment to cover this, but I thought I'd mention it. > + if (++loop_count > 4 || sp > addr_space_max) > { /* overflow, looks like end of stack */ > sp = this_base + info->size; > break; I'm wondering if 4 is enough to handle the eZ80 which has 24 bit addresses in extended mode? Should the limit change depending on the architecture? Or, alternately, maybe make the limit depend on the address width? It occurs to me too that the disjunct which matters most now is the loop_count check. The comparison against addr_space_max will rarely if ever be triggered. OTOH, I suppose it still could be when working at the very end/bottom of the stack. Regardless, it seems to me that the "overflow, looks like end of stack" comment should be revised as well. Kevin