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