From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7637 invoked by alias); 15 Nov 2012 22:21:18 -0000 Received: (qmail 7628 invoked by uid 22791); 15 Nov 2012 22:21:17 -0000 X-SWARE-Spam-Status: No, hits=0.5 required=5.0 tests=AWL,BAYES_00,KHOP_THREADED,RCVD_IN_BRBL_LASTEXT,RCVD_IN_HOSTKARMA_YE,RCVD_IN_MSPIKE_BL,RCVD_IN_MSPIKE_L3,RCVD_IN_NJABL_RELAY,RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from new.toad.com (HELO new.toad.com) (209.237.225.253) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Thu, 15 Nov 2012 22:21:12 +0000 Received: from new.toad.com (localhost.localdomain [127.0.0.1]) by new.toad.com (8.12.9/8.12.9) with ESMTP id qAFML62N024464; Thu, 15 Nov 2012 14:21:06 -0800 Message-Id: <201211152221.qAFML62N024464@new.toad.com> To: Tom Tromey cc: John Gilmore , Pedro Alves , Mark Kettenis , brobecker@adacore.com, gdb@sourceware.org Subject: Re: Time to expand "Program received signal" ? In-reply-to: <871ufu1zyx.fsf@fleche.redhat.com> References: <50A13A4E.3020000@redhat.com> <20121113162530.GX4847@adacore.com> <201211131640.qADGeKhs021376@glazunov.sibelius.xs4all.nl> <50A281BC.9030802@redhat.com> <201211132240.qADMeB2N032392@new.toad.com> <871ufu1zyx.fsf@fleche.redhat.com> Comments: In-reply-to Tom Tromey message dated "Thu, 15 Nov 2012 11:29:58 -0700." Date: Thu, 15 Nov 2012 22:21:00 -0000 From: John Gilmore X-IsSubscribed: yes Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2012-11/txt/msg00049.txt.bz2 > John> GDB shouldn't mention threads at all, unless the program being debugged > John> is multi-threaded. > > Why? What is the downside of the current approach? GDB is used by many novices at programming. I discovered early in my stewardship of it that the biggest thing that got in their way was its complexity. Roland Pesch and I shrunk the GDB manual into a reference card -- and put the six or seven commands that you actually NEEDED to know on the very front of the reference card. (gdb, b, bt, p, c, n, s.) It's in gdb-x.x/gdb/doc/refcard.tex. (It looks like it hasn't been updated since GDB version 5 -- and most places you find the refcard on the net are still offering version 4.) We used to ship the PostScript version, already formatted, in the release, so that people didn't need TeX to print one. This seems to have gone by the wayside too. Most folks on the web seem to offer it in PDF now. Anyway, we got so much good feedback from this "totally simple" introduction to gdb that we strove to keep the GDB user interface simple as well. GDB's strength comes not only from being able to do cool things like reverse execution, watchpoints, simulation, or cross debugging of arbitrary object file formats -- but also from being able to do simple things simply, to help simple or naive users get their work done. The debugger should "get out of the way" and let the user focus on interacting with the program being debugged. When a student is debugging their "hello world" style program, the last thing they need is for GDB to throw threads in their face. (It's already enough trouble that they have to ignore the long hex numbers printed in the backtrace, when using a "source level" debugger.) And if they don't have a positive experience while debugging a small program, they're less likely to try GDB for larger programs, nor plumb the depths of everything complicated that it can do for them. John PS: The Firesign Theatre made some good humor out of the crazy things that old DEC operating systems printed out all the time -- like "Amylfax shuffle time is less than 1% of freight drain." Let's not give them any more material to work with. Like, why do we print "[Thread debugging using libthread_db enabled]" when running a program? Was that a debugging message that nobody ever disabled?