Date:	Thu, 10 Mar 94 15:25:55 JST
From:	Stephen Turnbull <turnbull AT shako DOT sk DOT tsukuba DOT ac DOT jp>
To:	meetze AT charlie DOT ece DOT scarolina DOT edu
Cc:	djgpp AT sun DOT soe DOT clarkson DOT edu
Subject:	Who WAS that masked debugger? [was: symify ??? problems]

Dear Murle (and all the others who wanna know what's up with (e)debug32)--
    Your basic problem (I think) is that you haven't really got a good
idea what's going on inside the computer.  For example, I'd be willing
to bet based on the evidence in your correspondence to date that
what's going on is that you are implementing your queue as a doubly
linked list, accessing your queue once too often, and dereferencing an
uninitialized [last-in-node.backpointer], which points to memory that
your program doesn't own.  How does one figure this out?  Well, one
needs to know (1) what pointers are (no problem); (2) how the compiler
deals with them (usually pretty obscure); and (3) why this particular
error produces exceptions sometimes but not always (typically very
obscure).
    How does one get this knowledge?  Your best bet is to book up a
little.  (If this seems like too much to ask, you're probably right;
but then maybe you don't belong in DJGPP-town.)
    (1) Get a good book on assembler.  Short rather than long; you
don't want to be an assembler programmer, you want to be a C
programmer who understands the debugger output.  The intricacies of
assembler macros are irrelevant.  Besides, most assembler books will
tell you how to do MASM or TASM, and you want to be able to read GAS.
But they're not that different, aside from a few argument conventions
and mnemonics.  I don't have any recommendations; I learned more than
10 years ago from a book on 8080/Z80 programming whose title I don't
remember (that shows how little you really need!)
    (2) Get the most recent edition of Stroustrup and Ellis's C++
Manual and Reference (or whatever it's called).  The discussions of
implementations there are often obscure but give a feel for how things
are done in C and C++ generated code.
    (3) If you can find an MS-DOS version of Jim Hendrix's Small-C
compiler and book, look at that.  (There's something by that name in
.../msdos/c on simtel mirrors.  Just the source, according to the
00-Index, not the book.)  If not, get the 8080 version of the book;
you won't be able to execute the code produced but you can see how it
works.  The compiler construction stuff is horrible, a real kludge, no
modern tools, very limited set of data structures, and all that *but*
you get a working compiler that you can watch at work.  It produces
assembler output in a very small number of idioms with little
optimization.  That makes it easier to understand what the output is
supposed to be doing, even without interleaved C statements.  This
will give you a feel for the idea of a "compiler idiom", making it
much easier to cope with the much richer set of idioms produced by GCC
for the much more sophisticated 80386 family.
    (4) A little pointer is a dangerous thing.  Write that on the
blackboard 100,000 times.  You're allowed to cheat and write it this
way:
    FILE *blackboard = fopen(...);
    for (long i=0; i<100000; ++i)
        fprintf (blackboard, "%d. A pointer is a dangerous thing.\n", i);

Seriously, you just need to learn that *every* pointer is a likely
source of untrackable bugs.  Initialize *every* pointer, preferably
to something useful.  (Note that this can cause mysteries, too:
witness the recent discussion of read-only strings.)  Try to localize
pointer usage as much as possible in a small number of helper
functions.  Every time you declare a pointer cp, think "What happens
if I write c = *cp *right here*?"  Not only will this help you avoid
making mistakes, it's good training for working backward when your
program bombs anyway (thank you, Murphy).  After a while you'll begin
to get a feel for how exceptions are induced.
    (5) Play with a good full-screen debugger for another language.
(I use Zortech C/C++ and Multiscope, but I guess Borland "Turbo" or
Microsoft "Codeview" would be fine.)  This helps give a feel for how
computational code works.  Read their manuals on interfacing to
assembler.  This gives a feel for how function calls and the like
work.  There must be similar documentation for GCC, I haven't looked
for it though so I can't tell you where it is.
    That's the main stuff that I've used as background; I'm still
mystified by the organization of stack frames and stuff like that, but
I know how to go about learning them when I really need it.
    Good luck!  Remember, getting there's not half the fun, it's all
the fun.
    --Steve

- Raw text -