This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Time to expand "Program received signal" ?


> 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?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]