From: John Gilmore <gnu@toad.com>
To: Tom Tromey <tromey@redhat.com>
Cc: John Gilmore <gnu@toad.com>, Pedro Alves <palves@redhat.com>,
Mark Kettenis <mark.kettenis@xs4all.nl>,
brobecker@adacore.com, gdb@sourceware.org
Subject: Re: Time to expand "Program received signal" ?
Date: Thu, 15 Nov 2012 22:21:00 -0000 [thread overview]
Message-ID: <201211152221.qAFML62N024464@new.toad.com> (raw)
In-Reply-To: <871ufu1zyx.fsf@fleche.redhat.com>
> 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?
next prev parent reply other threads:[~2012-11-15 22:21 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-11-12 18:27 Pedro Alves
2012-11-13 16:25 ` Joel Brobecker
2012-11-13 16:40 ` Mark Kettenis
2012-11-13 17:22 ` Pedro Alves
2012-11-13 22:40 ` John Gilmore
2012-11-14 10:26 ` Pedro Alves
2012-11-14 19:54 ` John Gilmore
2012-11-15 10:36 ` Pedro Alves
2012-11-15 16:58 ` Eli Zaretskii
2012-11-15 17:21 ` Pedro Alves
2012-11-15 17:51 ` Joel Brobecker
2012-11-15 18:16 ` Eli Zaretskii
2012-11-15 18:27 ` Paul_Koning
2012-11-15 18:27 ` Pedro Alves
2012-11-15 19:07 ` Eli Zaretskii
2012-11-15 20:33 ` Pedro Alves
2012-11-15 20:58 ` Eli Zaretskii
2012-11-15 19:27 ` Tom Tromey
2012-11-15 22:21 ` John Gilmore [this message]
2012-11-15 22:27 ` Paul_Koning
2012-11-16 0:22 ` John Gilmore
2012-11-16 8:25 ` Eli Zaretskii
2012-11-13 17:23 ` Joel Brobecker
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201211152221.qAFML62N024464@new.toad.com \
--to=gnu@toad.com \
--cc=brobecker@adacore.com \
--cc=gdb@sourceware.org \
--cc=mark.kettenis@xs4all.nl \
--cc=palves@redhat.com \
--cc=tromey@redhat.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox