From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id uWBkFBRzMGke5xUAWB0awg (envelope-from ) for ; Wed, 03 Dec 2025 12:27:48 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1764782868; bh=EXBlm+u/zwP1NZfZBfPWDjmBbor2+ZNPrTZy5Puy7us=; h=Date:Subject:To:Cc:References:From:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From; b=acsQmyjeXOi76KgPYEkSH+iIvbyWlEO5nZFBKeV8OAEV/BAOzdHv/MU6AxqAd3iOi YOZrvBOsq8soY1IpnDtk6PxeRaDP06qp+9TCUrrt+Z4W/I4+z4R5RJywPwll2bq57Q HNzetR59Kjz41I4Ligcv4HHAMW1hXbZfrfw6+ets= Received: by simark.ca (Postfix, from userid 112) id 436261E08D; Wed, 03 Dec 2025 12:27:48 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-0.1 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, 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 Authentication-Results: simark.ca; dkim=pass (1024-bit key; unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=X8Om+bFr; dkim-atps=neutral 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 8B53B1E08D for ; Wed, 03 Dec 2025 12:27:47 -0500 (EST) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 1B3494209E15 for ; Wed, 3 Dec 2025 17:27:47 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 1B3494209E15 Authentication-Results: sourceware.org; dkim=pass (1024-bit key, unprotected) header.d=simark.ca header.i=@simark.ca header.a=rsa-sha256 header.s=mail header.b=X8Om+bFr Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 2AAB04CCCA24 for ; Wed, 3 Dec 2025 17:27:20 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 2AAB04CCCA24 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=simark.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=simark.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 2AAB04CCCA24 Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=158.69.221.121 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1764782840; cv=none; b=AlzVfQ+tNqqDUZlIL9fIAjt3i9M0jDFi2Q2KtIFKHQfUCS9w8ApRTCvlWstvdktslNQFAj5S6vZx6qcRNb26FYzPdZIXN5bX1dZ6whThoFn0oK9S/ipuht0PupZ+UoMfQ4aTue/mzC8ao6j8bzEXPaepyUz9BI/yawDZR2V8VwY= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1764782840; c=relaxed/simple; bh=EXBlm+u/zwP1NZfZBfPWDjmBbor2+ZNPrTZy5Puy7us=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=OiFeGevMSvIGrGic+oYc9Oj/9t6xDGzexMifu0oDiCepDmiRLhRMnpkGgw/d17qsWkDcW7US52LeE6kpYvzhDAMK9SrFjZVIBiW7czqRls4klPsUKoiD1wJ741JcMf83KOtrIemPWWtrnF8nQlAK3gjvYJCnBRIjjHH9JsPgZfc= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2AAB04CCCA24 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=simark.ca; s=mail; t=1764782839; bh=EXBlm+u/zwP1NZfZBfPWDjmBbor2+ZNPrTZy5Puy7us=; h=Date:Subject:To:Cc:References:From:In-Reply-To:From; b=X8Om+bFrpaPUi1eA2ExOBsGe3ip/Eczph3pkpudcgYdbB3INtuvpXfVQQI/XM3LBW Ol5O0d5IuAZoDMHA908YUt8HSxhTkbtHYHEs7RB0lx0agI93oHj5hXnyRhWrCIToWM +Wei93jAwHNvM4Kcf5hanZR4lxgd3d4svqxra7Fw= Received: by simark.ca (Postfix) id 9179D1E08D; Wed, 03 Dec 2025 12:27:19 -0500 (EST) Message-ID: <4528decb-897a-4d22-a27e-8ad67d13df58@simark.ca> Date: Wed, 3 Dec 2025 12:27:19 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] gdb: add tutorial command To: Guinevere Larsen , Eli Zaretskii Cc: gdb-patches@sourceware.org References: <20251201170819.1573624-1-guinevere@redhat.com> <864iq93qyw.fsf@gnu.org> <867bv33fd1.fsf@gnu.org> Content-Language: en-US From: Simon Marchi In-Reply-To: Content-Type: text/plain; charset=UTF-8 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 2025-12-03 08:07, Guinevere Larsen wrote: >> 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.) I agree that it's perhaps not necessary to have a program with a bug, and explain what is the bug, etc. It seems distracting to me. Having a program that does something simple (without being too trivial) would be sufficient to teach the user how to launch, navigate and print values. I have minor comments like this on the content of the tutorial but haven't had the time to formulate them. I thought we would resolve the more major issues / disagreements first. >> 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. > > It does matter that GDB is optimized, though. Assuming that the user could get debug info, they could use "next" and end up in a previous line because the compiler decided to reorder instructions/lines, they could try to step into a function that was entirely optimized away, they could try to read the value of a variable only to find that it was optimized away > > And, most importantly, if they aren't familiar with GDB, it isn't unreasnable to think they never used a debugger before and only did printf debugging. Having those confusing reactions would only cement in such user's brains that debuggers are actually not as useful as printf, because variables can disappear when they never do in a printf, for example. For this tutorial and the way it works (the user doing actions makes the tutorial progress forward), I think we need something extremely predictable. Using the GDB production binary is never going to work for that, on top of the other issues (like obtaining debug info). >> 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. > > These are most definitely out of scope for a tutorial that opens with "welcome to GDB" and assumes minimal knowledge of programming in general. But that's ok, because this doesn't have to be the only tutorial. What I'm presenting here is a quickstart tutorial, that'll get users acquainted with general purpose tools, and this framework can easily be expanded to have specific tutorials, like multi-threaded debugging, reverse debugging, linker namespace debugging and other advanced cases I haven't ran into. It seems like there is a disagreement on the target audience for this tutorial (which we could imagine being chapter 1 of a more comprehensive tutorial). Eli seems to think it should target seasoned programmers who write complex programs. Guinevere seems to think that it should be accessible to people who start programming. And I also think that it should be accessible to beginners, showing them early in their journey that debuggers are useful. Even if the example is a toy one, I think that experienced programmers will be able to extrapolate it to their own programs. We can discuss further how the material is presented exactly, but I think that the core of commands presented in this tutorial already goes a long way, even when debugging complex programs. > Also, I think it's worth to note that I haven't used any of the other commands. So unless my last 5 years of work experience (4 of them in GDB) aren't real life debugging sessions, I think you're overestimating the commonality of the issues you deal with. I agree, 95% of my day to day GDB usage to debug GDB must be: - break - run - print variable - step, step, next, finish - print variable - exit It's not to say that other commands aren't useful on occasion, but for the scope of a 10 minutes (or whatever is the maximum attention span nowadays) tutorial, I think it's fine. >> 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). > > Again, this isn't meant to be the tutorial that teaches all of GDB; to quote the tutorial's own opening words: "This quick tutorial should be enough to get ou acquainted with essential commands for basic debugging." > > Once a first tutorial goes through and we have a basic framework for how to teach things to users, you're welcome to try your hand at teaching the advanced techniques with a tutorial of your own, say "tutorial multithreaded" for example. Off the top of my head, I think that conditional breakpoints should be explained. They are relatively simple to use and useful in real-world situations. But this introduction tutorial would not be the right place, perhaps in an eventual subsequent chapter. >> 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. I don't really see it as showing debugging techniques. The tutorial with the toy example allows users to try the GDB command being taught for themselves and see the result. Which I guess is the point of an interactive tutorial, over just a list of "command X does that". Simon