From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id KcQXEMGwlGmTID8AWB0awg (envelope-from ) for ; Tue, 17 Feb 2026 13:17:37 -0500 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=UW9o5zt1; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 3AB2C1E08D; Tue, 17 Feb 2026 13:17:37 -0500 (EST) 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 613461E08D for ; Tue, 17 Feb 2026 13:17:36 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id A181B4B9DB4F for ; Tue, 17 Feb 2026 18:17:34 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org A181B4B9DB4F 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=UW9o5zt1 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 0D1D34BA23CB for ; Tue, 17 Feb 2026 18:17:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 0D1D34BA23CB 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 0D1D34BA23CB Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=170.10.133.124 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1771352227; cv=none; b=koWtIk4CM4sqCOAna4nSEgA+Q6MCYPVl7Md7h5tKxLQ/YWnhxW0lYT6xHv+Kqp6JiouJUiZWwAMBXXcrBADTMylR1o6HeIk9Ze6WissDDxoHH5V0Mmlo2XtxIDK0t0HRXRJj+1k48pBAWzh7NQsBvywoj1mwOfkzJZpm9BJcunE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1771352227; c=relaxed/simple; bh=B3CGUyResIyLEaQ8JfMowcVI1lynfiHgDoFJP/vPn1U=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=kH7n1NPrslRSTqU8MBMWJwuW7YUmhDIVUssq0c4XUBdTEkHYhJXDiuXkBkQvSjI9L+E6u3OTs9MXot/xG8BzcQeVC2Vm5hwGaEu5AYR1RO+kj9LwluZFq0uGewDOxBFg2IEhSuc/SFH54OHTkQH8iPtJRc62Op4Fbih9Af4Zbqs= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 0D1D34BA23CB DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1771352226; 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=M2LUfvEliS2Lz1zHJl6d9woaeqwmw+cWVffNaz7a2EA=; b=UW9o5zt1VN9SDmhCcLNPa5IBppQwmEcfG6rPMxYmr3fj+lEYZiUPX4BH+tWROYO4xKaV37 V5sYuggTiCUuAClJD2p/oxVUON1pdTQPTGWcfuq9htNYYNSCucDKLK3py7wF8LGWCbTUao G1AWV0F2oleLqHWCkjjp0x/HjguWoEQ= Received: from mx-prod-mc-01.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-422-d65z9ZALMK2KpbjykET3Wg-1; Tue, 17 Feb 2026 13:17:03 -0500 X-MC-Unique: d65z9ZALMK2KpbjykET3Wg-1 X-Mimecast-MFC-AGG-ID: d65z9ZALMK2KpbjykET3Wg_1771352222 Received: from mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com [10.30.177.111]) (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-01.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id 717C0195605B; Tue, 17 Feb 2026 18:17:02 +0000 (UTC) Received: from f42-zbm-amd (unknown [10.22.80.38]) by mx-prod-int-08.mail-002.prod.us-west-2.aws.redhat.com (Postfix) with ESMTPS id A4C731800351; Tue, 17 Feb 2026 18:17:01 +0000 (UTC) Date: Tue, 17 Feb 2026 11:16:58 -0700 From: Kevin Buettner To: "Schimpe, Christina" Cc: gdb-patches@sourceware.org Subject: Re: [PATCH v2] gcore: Handle unreadable pages within readable memory regions Message-ID: <20260217111658.0671d87f@f42-zbm-amd> In-Reply-To: References: <20260212194039.1717054-1-kevinb@redhat.com> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.4.1 on 10.30.177.111 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: zrGLYwuw_KyfWAE7jhwWKeFrHaWhvHS_hU8RJSXM7Ls_1771352222 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 On Tue, 17 Feb 2026 17:44:06 +0000 "Schimpe, Christina" wrote: > > Claude Opus 4.5 and GLM 4.7 assisted with the development of this > > commit. > > For binutils there is a guideline for LLM generated content: > https://sourceware.org/binutils/wiki/LLM_Generated_Content > > Do we have something similar for GDB ? Not yet. IMO, the GDB project should adopt the same guidelines that binutils uses. Until we have a policy in place, I encourage all GDB contributors to follow the binutils policy when using LLMs. For my contributions to the GDB project, I am using AI / LLMs to help me understand code and diagnose problems, but I am instructing the models I use to not generate patches for me, nor show me new code. Instead, I am instructing them to write English language descriptions of how the code might be fixed as part of its analysis. With that in hand, I write the patch myself. E.g. I used Claude Code yesterday to find a problem in what I thought to be a bit of build infrastructure. (But it turned out to be a bug in GDB's testsuite, for which I'll be submitting a patch.) In any case, once it had found the bug, I instructed it: Please make a markdown file describing the problem in detail along with your fix proposals. Place the markdown file in the home directory ($HOME) and tell me the path to it when you're done. I will likely go with option 2 in which I submit a patch fixing this problem, but I may wish to discuss it with my colleagues first, which is why I want a comprehensive write-up. Don't show your fixes in the form of patches; instead describe in English how the bug might be fixed for each of your proposals. The reason for this is that, although GDB does not have an AI/LLM policy yet, many other related projects (such as binutils and elfutils) are instituting policies about LLM generated code. So... I don't want a patch from you, merely really good documentation about what the problem is and English language descriptions about how it may be fixed. You may, of course, show existing code and its problems in your summary. You just can't show me new code which fixes the problem. Instructions like this might also be placed in a CLAUDE.md or AGENTS.md file. Kevin