From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id qhC5EgJuc2q3WAoAWB0awg (envelope-from ) for ; Wed, 05 Aug 2026 13:08:18 -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=S10AY/CH; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 238BD1E166; Wed, 05 Aug 2026 13:08:18 -0400 (EDT) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-6.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 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 0BB941E09B for ; Wed, 05 Aug 2026 13:08:17 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 8F16E4BA2E3B for ; Wed, 5 Aug 2026 17:08:15 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 8F16E4BA2E3B 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=S10AY/CH 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 4A6114BA2E3B for ; Wed, 5 Aug 2026 17:07:49 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 4A6114BA2E3B 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 4A6114BA2E3B 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=1785949670; cv=none; b=N0lfBept8E3kd7+6BdVOEkk9bZ45npg5oCye7EigLHfODbfvOL0HNnW7UoN11Nd3OEN7Oodrk8CNYDKUId74nuM7uKZlAtRyRY273oBYfTGGiQFCg0tBgyMHQINm2CJ53mZaP27XCQ/gBHluGAJ/HoJ/nRh/+cC650tL/fzyhFQ= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1785949670; c=relaxed/simple; bh=dmLJsoRv1CoCctrRZflvdnPVP6HCa02NtHpyALs1fhI=; h=DKIM-Signature:From:To:Subject:Date:Message-ID:MIME-Version; b=CuezKJrFFXTe7OrGBu+2bWHMxZKY0ArtsqS0MPS5meaJWbEFoJa8p7aWCzyQ2NL/TGPl9Iemmx+0J+aqITAS30g5WdwISeFqCZsNIUjwZmu+FYxiQTKx/KrgWH+l/Tq+RaGr5/T9oBZaPyhKIarh+D9no0DilfowRVeqITRVLXc= 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=S10AY/CH DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 4A6114BA2E3B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1785949668; 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: in-reply-to:in-reply-to:references:references; bh=TQ6uf0Rf2MllFjOOAJOedqhVYfmHJ2OXiteL8twSFcY=; b=S10AY/CH5oZ6JEYXI8Uc4+l36ag3HkWF5DLDwzVcy1ofvBYar4xtkEK/yxDcbzT/Kpb4sE j3CSyepmdu3eHoOIc9116q9eqAMpPKYaygPpRZXv21VojqrKeCJj1WoM2DJNxc5Un0vxKW iertIAKmnKNyb4aD3G/25nl/2Nv7Cak= Received: from mail-wr1-f71.google.com (mail-wr1-f71.google.com [209.85.221.71]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-644-akFMQ2MrPA-En0gdP63f4g-1; Wed, 05 Aug 2026 13:07:46 -0400 X-MC-Unique: akFMQ2MrPA-En0gdP63f4g-1 X-Mimecast-MFC-AGG-ID: akFMQ2MrPA-En0gdP63f4g_1785949666 Received: by mail-wr1-f71.google.com with SMTP id ffacd0b85a97d-47f753a0aa0so703135f8f.3 for ; Wed, 05 Aug 2026 10:07:46 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20251104; t=1785949665; x=1786554465; h=content-type:mime-version:message-id:date:references:in-reply-to :subject:cc:to:from:x-gm-gg:x-gm-message-state:from:to:cc:subject :date:message-id:reply-to:content-type; bh=TQ6uf0Rf2MllFjOOAJOedqhVYfmHJ2OXiteL8twSFcY=; b=G0bQcuoIYkC73mWP14QnTeC3QMHSzsh4fW1MhGPX1WnO8dz+uferIjLUeqUe7eLc4I x9Z5KNvQsTrhobQQxMHv69Wan2FzO7mvfFWA+laZpKBtP+vPHhssWwb6Fi+iQ6R4ykcG WMM6D7R2YFaYb9JKh4LetwRN26+q0J6ejN4dYWLRu/jdJnUZYkyIQ5at+w9d+zm1FkXX i8xT1pyPb2BonG59Zbw/aBB6aAmm01lOhFgy1/BYgpJ9FbpjfzNqi6fo5A14SZdkJscM JXIfkeBdjWkel2mJ+HaTHKNnuiVYIg5iUwOz4wyViBByZ0FwJWUFHgU0AXZ1qrguq4/J jhrA== X-Forwarded-Encrypted: i=1; AHgh+Rq0wsOSD+1grfSlRvWTzkBRUP4SAq6GV0kWi0wH1xpn6O4vq38Ahr0YSGqW8XXXg5xZBaC24lhgqDlDgA==@sourceware.org X-Gm-Message-State: AOJu0YxKc+eHT/frdB9hvta3xd1Brom1Fn/mebqBEtcKP9fQLVVltLMr N4+pfwexNZ3OCOE2h2I2cg4Lrpz/LJXHGOIErLtTPxtxyDv/v9Bp4BVc7d6EAY6cJ8ZfwKLiBVx ieChutR1A93znLGRzbiZ8PMC0HbDpyBxldhEiKAOh7fjqmsyU3pzxb7Fo0CccCv4= X-Gm-Gg: AR+sD13FCdfBeQ/1jNSQv55iqatr6rhGP2QG4p5pS+/5AkLxzOEKXa6y76pCj30XaSL z+WPKkvgtxQbrmGclv4C4eI4DKbRkV+zPQSROCLP6+HHRWzAM93LAbQeOaEeaQhermQjYLjfANT ISmh8y6jN+PrFYtUpBJMIpLcEjHVG/Rb5IEdcY/XmOYiSIpSb8ERwQbxzOpVN3CTkGmlGLuNHAM hzHTqzdC7S7TqNGDiKfdS+TcYRzWgnavuNR/AnxFArXZWGV1/vf3Z5Fs8LlgMClrzM/1Hzbqteq 3gTglr5Wx3dmJyaOebFU6YBEKvSDEHjuzUuf0mX9MsyPN6JPKnPKMB5NXAeOnldhqpJJBS0YMAf Uwd0dPBteufYSSS4n1purBzXx X-Received: by 2002:a05:6000:290d:b0:47f:f42e:9715 with SMTP id ffacd0b85a97d-47ff42e974fmr2330244f8f.12.1785949665470; Wed, 05 Aug 2026 10:07:45 -0700 (PDT) X-Received: by 2002:a05:6000:290d:b0:47f:f42e:9715 with SMTP id ffacd0b85a97d-47ff42e974fmr2330120f8f.12.1785949664970; Wed, 05 Aug 2026 10:07:44 -0700 (PDT) Received: from localhost (227.114.208.46.dyn.plus.net. [46.208.114.227]) by smtp.gmail.com with ESMTPSA id ffacd0b85a97d-47ff34da5c4sm1998044f8f.5.2026.08.05.10.07.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 05 Aug 2026 10:07:44 -0700 (PDT) From: Andrew Burgess To: Tom Tromey , gdb-patches@sourceware.org Cc: Tom Tromey Subject: Re: [PATCH] Always fetch Ada "main" name from the executable In-Reply-To: <20260730170336.2547536-1-tromey@adacore.com> References: <20260730170336.2547536-1-tromey@adacore.com> Date: Wed, 05 Aug 2026 18:07:43 +0100 Message-ID: <87qzkclcm8.fsf@redhat.com> MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: zRPiQ0EaUlyTu9FsObU2J_02yyKMnEoOq6k2dF1NO7g_1785949666 X-Mimecast-Originator: redhat.com Content-Type: text/plain 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 Tom Tromey writes: > The gdb.ada/file-then-restart.exp test was failing with gnat-llvm. I > tracked this down to the "main" name not being stored in a readonly > section, meaning that the code in ada_main_name using trust_readonly > did not work. > > However, it seems to me that gdb should always prefer the data from > the executable in this particular case. So, rather than relying on > trust_readonly, this patch changes gdb to do this directly. I was pointed at this: https://sourceware.org/pipermail/bunsen/2026q3/001484.html It's an AI/LLM code review of this patch. The review in this case seems to be totally bogus, everything it is commenting on is either fine, or is part of the documented API of the function. However, I asked Claude to review the patch and it did highlight one issue. It's mostly theoretical, but fixing it is trivial, so we might as well. Let me know what you think. Thanks, Andrew --- commit 5990efb77092a3a02330260b88899d5a8b15bca7 Author: Andrew Burgess Date: Wed Aug 5 17:23:38 2026 +0100 gdb/ada: avoid rereading stale main name data in edge case The commit: commit 8eafbbc74748e499ec785f78858687bd7ea79005 Date: Wed Jul 29 12:40:03 2026 -0600 Always fetch Ada "main" name from the executable changes ada_main_name to use section_table_xfer_memory_partial. This introduced a highly unlikely, but theoretical bug where stale buffer data could cause GDB to find an invalid name for "main". Looking at ada_main_name (in ada-lang.c), the steps to reproduce the bug are: 1. Debug a program that causes the static buffer main_program_name to have some content written to it. For the sake of this bug let's assume the main name is "xxxxxxxxxx", the main_program_name buffer will contain 10 'x' characters, a null byte, then whatever happened to be in the section after that. 2. A new executable is loaded into GDB and ada_main_name is called again. 3. For whatever reason the new executable is maybe not correct. The ADA_MAIN_PROGRAM_SYMBOL_NAME symbol points to an address 5 bytes before the end of a section. None of these 5 bytes are a null bytes. Let's assume these 5 bytes are "aaaaa". 4. The section_table_xfer_memory_partial call will try to read up to 1024 bytes, but as there are only 5 bytes left in the section, only 5 will be read. This leaves the main_program_name buffer containing "aaaaaxxxxx" followed by a null character byte. 5. GDB returns this merged string as the result from ada_main_name. Now given this depends on the second executable being broken, we maybe don't really care too much, however, fixing this is pretty easy. The current code already checks: && (strnlen ((char *) main_program_name, sizeof (main_program_name)) < sizeof (main_program_name)) This ensures that there's a string with a null byte contained within the buffer, but makes the assumption that we always read sizeof (main_program_name) bytes from the section. But we know how many bytes were read, that's the value in XFERRED. What we really want to ask is: was there a null terminated string within the bytes that we just read. This is: && (strnlen ((char *) main_program_name, xferred) < xferred) Given how simple this fix is, let's make it. diff --git a/gdb/ada-lang.c b/gdb/ada-lang.c index 906c5cd3465..174e04af04c 100644 --- a/gdb/ada-lang.c +++ b/gdb/ada-lang.c @@ -806,8 +806,7 @@ ada_main_name () sections) == TARGET_XFER_OK) && xferred > 0 - && (strnlen ((char *) main_program_name, sizeof (main_program_name)) - < sizeof (main_program_name))) + && (strnlen ((char *) main_program_name, xferred) < xferred)) return (char *) main_program_name; }