From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id E8/6KU4xMGkh8hQAWB0awg (envelope-from ) for ; Wed, 03 Dec 2025 07:47:10 -0500 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=OGLD7aDM; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 9C96A1E0B3; Wed, 03 Dec 2025 07:47:10 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-1.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_VALIDITY_CERTIFIED_BLOCKED,RCVD_IN_VALIDITY_RPBL_BLOCKED, RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=no autolearn_force=no version=4.0.1 Received: from 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 E4FD51E08D for ; Wed, 03 Dec 2025 07:47:09 -0500 (EST) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6711C48EBBE1 for ; Wed, 3 Dec 2025 12:47:09 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6711C48EBBE1 Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=gnu.org header.i=@gnu.org header.a=rsa-sha256 header.s=fencepost-gnu-org header.b=OGLD7aDM Received: from eggs.gnu.org (eggs.gnu.org [209.51.188.92]) by sourceware.org (Postfix) with ESMTPS id C18BF4BB3BC3 for ; Wed, 3 Dec 2025 12:43:40 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org C18BF4BB3BC3 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gnu.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gnu.org ARC-Filter: OpenARC Filter v1.0.0 sourceware.org C18BF4BB3BC3 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=209.51.188.92 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1764765820; cv=none; b=lrUThbwJDD7XaqSy/z7klmvxUCwoNR21yyJy2D+LMxAQo5BKc9c5CwT73PbQLcZwvwNMv9PfWDoHP7GLzlHBHu2wKCnIBBoizAZzrIc8mbx+SOyB821L6UsunsZ7tSd+OnzEt0SnwAttQBh4J9FDzM/EcN2q24t/Z1DE52CE/kM= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1764765820; c=relaxed/simple; bh=oJjrG45gqjuKUGq56un8jlexSwZhxgMq62S4qerRJxc=; h=DKIM-Signature:Date:Message-Id:From:To:Subject; b=W8WI5b1Qs0bhl3YQtzy6M8C3QCAnV6rAIMwGGjxOxzduHKntJ2zCcNH3jN026rPGGDq/+/UI+qKqxyhe8ol6pDHOht4575tAP/akPeQwXH8pEUtvo/Ue78mPJLpvRXL3OXcxsxQoVFtLghg/XLiFaaSasTBoKG9GXuV9A3ZnnN0= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org C18BF4BB3BC3 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1vQmCq-00063F-3O; Wed, 03 Dec 2025 07:43:40 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=whHfdj6KnnhlwdhEbEaDFsNSud082pJjfVW7O8JR2fE=; b=OGLD7aDMgLXp c8AlIpawqGn38d/ANwfjdWUm8T5LJXvTnuSTOoOtVztBgjaR8uswigsohvtq+X8T+dtKyTkJvf5gL E28srSgqaj14Mo9SEkisoe+3kdusYYQ5SlW55nfJiL8sftFflbnDGoDMLV58ie7MMEZCoOVCzd8/q V32g9njKT4vicZC9XlUfQFatKulJzP+pOR5QG2H1jLAEBs5e4K2G8dXmKzUqwBgcRfYiLJhgYN5KL QfjD3mzSx5hKKx5Q7ly5zwZgekyrTk27UnmDRDOQzmFrs4H4hoRkJN365IrTDIZ1TycjnweXqg+Xa rEgdG33YkQz18db+S0Wxew==; Date: Wed, 03 Dec 2025 14:43:38 +0200 Message-Id: <867bv33fd1.fsf@gnu.org> From: Eli Zaretskii To: Simon Marchi Cc: guinevere@redhat.com, gdb-patches@sourceware.org In-Reply-To: (message from Simon Marchi on Tue, 2 Dec 2025 14:33:08 -0500) Subject: Re: [PATCH] gdb: add tutorial command References: <20251201170819.1573624-1-guinevere@redhat.com> <864iq93qyw.fsf@gnu.org> 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 > Date: Tue, 2 Dec 2025 14:33:08 -0500 > Cc: gdb-patches@sourceware.org > From: Simon Marchi > > > First, writing this command in Python means that GDB without Python > > will not have a tutorial, which is IMO a pity. Is it so complicated > > to have this implemented in C++ instead? The text and the basic > > script of the tutorial session could be on a text file that code > > accesses when the tutorial is running, so that only the necessary > > stuff needs to be in code. > > If possible, it would indeed be nice, but I'll take a tutorial written > in Python over nothing. If the C++ implementation is not feasible or not practical, I agree. My point is that we should consider that possibility before deciding on a Python implementation. > > Next, I'm not sure we need to compile a program for this purpose. We > > could use the GDB executable itself instead: that would allow us to > > show the basic commands without the need for the user to have a > > compiler and a working development environment to go with it. > > I don't see how that's feasible or practical. The GDB binary users are > most likely to have are optimized (bad debugging experience, especially > if you're learning) and won't have debug info anyway. And like > Guinevere said, GDB is way too complicated to throw at newbies anyway. > I like Guinevere's idea of giving the user a small program they can toy > with. This is a _GDB_ tutorial. It doesn't need to include a complete debugging problem described in its entirety, right up to finding the bug and fixing it. It needs to show the use of important GDB commands, under the assumption that the person using the tutorial knows how to debug programs, but is not familiar with GDB commands to do that. (Yes, teaching debugging techniques in addition is helpful, but IMO the minimal requirements from a useful tutorial are to teach the commands.) For the purpose of teaching the useful commands, it doesn't matter much that GDB is optimized, the only possible problem could be that it's stripped. If it is not stripped, I don't see why we couldn't show use of important commands on GDB itself, explaining their purpose in plain text. There's no need to solve an actual bug, just let users tinker with commands when they have a live program at their disposal. Whatever the complexity of GDB, users definitely can step it, step into functions, examine its data, set breakpoints and watchpoints and see them break, etc. We could also show how to change values of variables and call functions from the program. Moreover, if we limit ourselves to teaching commands, we can show advanced commands and techniques, like working with threads and scheduling them, following 'fork', handling signals, etc. -- these are hard to impossible to do with toy programs, but they are needed in most real-life debugging sessions. > > Also, a tutorial doesn't have to teach people how to debug, it could > > only teach them the important GDB commands to use for debugging. > > Doing both makes the tutorial more complex because it teaches two > > non-trivial subjects instead of just one. > > > > What do others think? > > I don't understand your last point. Do you mean that the tutorial > should just be some text that says "you can use command X to do this, > command Y to do that, etc"? Seems way less interesting and interactive > than what is proposed here. Yes, I mean just describe the important commands and let the user try them and see the results. Indeed, teaching both debugging techniques and GDB commands is better, but that job is much more complex if taken seriously. And I question the actual value of showing how to debug a toy program anyway, because it is nothing like debugging real-life programs. The latter frequently requires advanced techniques, some of them special to the program in question (e.g., see etc/DEBUG in the Emacs source tree). So I suggest to start from a modest task of showing and teaching the important commands, leaving the rest to the users, who will need to learn much more, if they never debugged a real-life program. We may decide in the future to have a separate tutorial about debugging techniques. Please note that the above is just MO; I will not object and won't argue if you-all think differently. I just wanted to present an alternative POV, so that people could think about this and make up their minds. After all, it is unlikely that I will use this tutorial myself...