Compiler features

Chris Torek chris at umcp-cs.UUCP
Sat May 31 19:58:11 AEST 1986


In article <312 at uw-nsr.UUCP> john at uw-nsr.UUCP (John Sambrook) writes:
>While on the subject of compilers ...
>
>The first feature is the ability to generate a stack trace ("traceback") 
>in the event of a serious error.  There are two compiler switches that
>control the amount of information in a traceback.  The "-Clineid" switch
>causes the offending line number to be included while the "-Cprocid" switch 
>causes the procedure name to be included.

On 4BSD, compile with the `-g' switch and run sdb or dbx whenever
you see `(core dumped)' messages, and you not only get a traceback,
you can also examine variables, and in general poke around in the
data and stack space of the now-defunct process.  It takes a bit
more manual intervention, but amounts to the same thing.

(The 4.2BSD dbx is terribly buggy.  To repeat the old war cry:
`fixed in 4.3'---which (fanfare please) *has been released!*...)

>The second feature is the ability to declare certain data structures as
>"read only." This is done via a compiler switch "-R" and applies to all 
>data structures that are initialized to a constant value within the 
>compilation unit.

Surprise!  4BSD has the very same feature.  It is even documented.
(At least in 4.3; if it is not documented in 4.2, well, `fixed in
...'.)  This is perhaps most useful to make the text of string
constants sharable.

>Here is an example program that demonstrates both features:
[deleted; it appears again later]
>Executing the program produced the following output on stderr:
>
>	a: 1  b: 1
>	
>	ERROR         71237.
>	from line 13 of main.
>	
>	Call Traceback:
>	
>	from fp=16000002722,  pc=16001754200,   line 10 of main
>	from fp=          0,  pc=16001762472
>	
>	Hardware protection violation: Write access denied.
>
>... while I hate to see any tracebacks, I find them to be far better
>than:
>
>	% mumble foo bar
>	Segmentation violation - core dumped.
>	%

The latter is not too hard to deal with *if* one compiles with -g
(or is prepared to use adb and find source lines by hand).  Here
is what happens when I do the same thing under 4.3:

	% cc -g -R -o xx xx.c
	% ./xx
	a: 1  b: 1
	Bus error (core dumped)
	% dbx xx
	dbx version 3.11 of 2/28/86 22:38 (gyre).
	Type 'help' for help.
	reading symbolic information ...
	[using memory image in core]
	(dbx) where
	main(0x1, 0x7fffe9e4, 0x7fffe9ec), line 13 in "xx.c"
	(dbx) list 1,99
	    1   int a = 1;				/* "read only" */
	    2   
	    3   main() {
	    4       	int	b;			/* "read / write" */
	    5   
	    6   	/* this is legal */
	    7   	b = a;
	    8   
	    9   	/* prove it */
	   10   	printf("a: %d  b: %d\n", a, b);
	   11   
	   12   	/* this is not */
	   13   	a = 2;
	   14   
	   15   	/* lie detector */
	   16   	printf("Can't happen\n");
	   17   }
	(dbx) print a, b
	1 1 
	(dbx) quit
	%

The point of all this is that the information is there in the core
dump, and there are programs for dealing with core dumps, so do
not let the dreaded `segmentation fault' fash you.
-- 
In-Real-Life: Chris Torek, Univ of MD Comp Sci Dept (+1 301 454 1516)
UUCP:	seismo!umcp-cs!chris
CSNet:	chris at umcp-cs		ARPA:	chris at mimsy.umd.edu



More information about the Comp.lang.c mailing list