mb@pertec.UUCP (mike burg) (01/08/85)
Seeing the entries on unix-wizards and net.sources about debuging
C code, I thought I might bring up some more talk about this.
A couple of nights ago I was debuging code (ugh) and was wonder if
there was any other debuging package other than adb and the recent debuging
package posted to net.sources that told the programer which line the program
bombed on.
Now, usualy you run adb on your program and your program's core to
find out what subroutine it blew up in and at what instruction. Well that's
fine if you know how the system's compiler procduces instruction for each
line of code. Or, if you don't know assembly and only know how to type
$C in adb for a traceback on the stack (or even you don't know that),
you usualy end up bombing your program/subroutine with printf()'s. Well, that's
okay, if your subroutine doesn't go into long loops were as you have to sit
there for hours until you find out what last printf() it ran before finnaly
dying. Has there been any atempts to modified the C compiler to produce
line tracking code? For example:
main() {
char *ptr;
ptr = (char *) malloc(5);
ptr[5] = 0;
}
Will probably cause the program to abort due to the overindexing of
ptr. Now, if you told the compiler to procduce code that keep track of which
line number, how about some like this (on a PDP-11):
.text
.globl ~main
.globl csv,cret
~main: jsr r5,csv
sub $4,r5 (or is it sp?)
mov $2,linenum / ptr = (char *) malloc(5)
mov $5,-(sp)
jsr pc,~malloc
tst (sp)+
mov r0,-4(sp) / ptr = return result of malloc()
mov $3,linenum / ptr[5] = 0
mov -4(sp),r0
add $5,r0
clr (r0)
rts pc / return from main
Now in the csv and cret the var linenum could be push onto the stack
for subroutine call return. Several problems arise with this method, 1) It
uses up three words of memory for every line of the program and another word
if it was to be pushed on the stack and, 2) This would require modifing the
the C compile, csv/cret routines and adb to understand the extra word on the
stack. But one of the advantages of this is that you could just:
% cc -j prog.c (using -j to tell the compiler to procduce line tracking code)
% a.out
Segmentation Voliation -- core dumped
% adb a.out core
$r
pc 010000
sp 017760
r5 017755
...
..
r0 017754
linenum 3
~main+xxx: clr (r0)
and new it crashed around line 3.
Has anyone try this or any thing simular to this? Any other ideas??
(has this been talk about on here before??)
Mike Burg
decvax!trwrb!pertec!mb
PS, Forgive me if I did anything wrong..I'm sorta new to the net. Doug Gwyn (VLD/VMB) <gwyn@Brl-Vld.ARPA> (01/09/85)
csv?? Boy do you have an old PDP-11 compiler! Modern C compilers, such as the current PCC, generate much more useful symbol table information. There are symbolic debuggers that make use of this information to make debugging much more pleasant than using "adb". 4.2BSD has a debugger called "dbx", and UNIX System V has "sdb" (using a much richer symbol table). The niftiest debugger I have seen so far is "joff" (aka "dmdebug"); it runs in a DMD (5620, BLIT) layer and lets one snoop around in code running in any layer. It even understands DMD graphic primitives so it can illuminate the rectangle in question, and so forth. Too bad it doesn't let one debug code on the host too.
ron@brl-tgr.ARPA (Ron Natalie <ron>) (01/10/85)
The C compiler AT&T wrote for the WE32000 processor seems to get the line numbers into the object code some how, but I haven't looked at the code carefully enough to figure out how it is done. -Ron
gwyn@brl-tgr.ARPA (Doug Gwyn <gwyn>) (01/11/85)
> The C compiler AT&T wrote for the WE32000 processor seems to get the > line numbers into the object code some how ... All a part of the standard AT&T SGS COFF symbol table. (Aren't acronyms great?)