I HATE DBX! I HATE DBX!

[Pat Shanahan]

In article <1700 at utah-gr.UUCP> thomas at utah-gr.UUCP (Spencer W. Thomas) writes:
>In article <169 at gsg.UUCP> kathy at gsg.UUCP (Kathryn Smith) writes:
>>
>After running some tests then recomiling the
>>application to use SDB instead, it turned out that DBX requires somewhere
>>between 10 and 15 times the memory resources that the same program compiled with
>>SDB requires.
>
>The reason for this is that dbx knows so much more about your program.
>Basically, you are seeing the difference in the symbol table sizes
>between sdb and dbx.  Dbx also has all the type information compiled
>into the symbol table.  
....
>-- 
>=Spencer   ({ihnp4,decvax}!utah-cs!thomas, thomas at utah-cs.ARPA)

Since Celerity systems are used to run some large programs, this was a real
problem for us and some of our users. It is not really desirable to require
the swap space to be many times the size of the largest program that is ever
going to run on the system in order to debug it. Even with a big swap space
the time for dbx to read the symbol table and build its internal table may
be prohibitive. On the other hand dbx's very detailed information does help
with debug. 

The solution that we have implemented for our version of dbx is to collect a
very limited amount of data about each compilation unit in the program
during the initial load. Each time the user enters some command that relates
to a new compilation unit, dbx reads in the full information about that
compilation unit. In practice, very big programs are usually divided into a
large number of reasonable size compilation units. During a single debug
session the user will only reference a few of them.
-- 
	ps
	(Pat Shanahan)
	uucp : {decvax!ucbvax || ihnp4 || philabs}!sdcsvax!celerity!ps
	arpa : sdcsvax!celerity!ps at nosc