massar@think.ARPA (JP Massar) (03/04/86)
FLAME ON
I've really had it up to you know where with DBX. The next time it
tells me '<variable> is not active' I think I will list out the code,
tear it into tiny, tiny bits and sprinkle it out over the Charles River...
FLAME OFF
Does anyone have/know-of a REAL, reasonably bug-free, powerful
'C' debugger (public domain or commercial) that runs on VAX BSD4[23]?
Is the 4.3 dbx by any chance new and improved?
I will summarize replies.
--
-- JP Massar, Thinking Machines Corporation, Cambridge, MA
-- ihnp4!think!massar, massar@think.com
-- 617-876-1111mp@allegra.UUCP (Mark Plotnick) (03/05/86)
In article <4473@think.ARPA>, massar@think.ARPA rants and raves
("raves" is possibly not the right word to use here) about dbx.
The vanilla 4.2bsd dbx gave "<variable> is not active" errors when you
were stopped inside a nested block because its findframe() routine was
a bit simplistic. It just walked down (or is it up - we're talking
about a vax here, after all) the stack by following the saved frame
pointers. Mark Linton, the author, posted a large set of diffs in 1984
that fixed this and many other bugs (briefly, it needs to check if the
current function is an "inline" function, and if so should look at its
"container" rather than blindly calling nextframe()).
One problem I've found in the 1984 version and the 4.3bsd-beta version
is that occasionally dbx will get confused when the PC is in
sigtramp-land (somewhere above your stack base, around the u area). It
prints the arguments to the current function (in my case, this is
typically a select() that's been interrupted by an alarm or int signal)
correctly, but claims the name of the function is sbrk or printf. It
then frequently doesn't give a stack trace longer than one function. If
anyone has a fix for this, let me know.
While we're on the subject of dbx bugs, you may want to change
the restoretty() function to do
ioctl(fileno(f), TIOCSETN, t);
rather than
stty(fileno(f), t);
so that when a signal that's not being caught by dbx comes in (for
instance, dbx normally does nothing with an alarm signal except reflect
it back to the process), your pending typein won't get flushed.
Mark Plotnick
allegra!mpkathy@gsg.UUCP (Kathryn Smith) (03/06/86)
We started using DBX here when we got it on our Pyramid, but flushed it fairly quickly after discovering some of its properties. We wanted to use it on some large executables, and started running into problems almost immediately. The error messages varied somewhat, but it boiled down to the simple fact that we couldn't have more than one person running DBX on this project at once. This struck as as sort of unreasonable, since we were running on a reasonably large system (a Pyramid 90x), so we started looking at how much memory the thing was using. 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. This makes DBX practically useles for anything but trivial development. Is this a problem peculiar to Pyramid's release of it, or is it universal? Kathryn Smith (...decvax!gsg!kathy) General Systems Group Salem, NH
thomas@utah-gr.UUCP (Spencer W. Thomas) (03/09/86)
In article <169@gsg.UUCP> kathy@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. If you are running programs that are so big you can only run one dbx at a time, I would look at the sizes of your swap partitions and how much main memory you've got. (You didn't say exactly why you could only run one at a time, but I assume it must be one of these.) Usually, big symbol tables come from big programs, and big programs have a tendency to eventually fill memory. -- =Spencer ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA)
doug@tolerant.UUCP (Doug Doucette) (03/11/86)
In article <1700@utah-gr.UUCP> thomas@utah-gr.UUCP (Spencer W. Thomas) writes: >In article <169@gsg.UUCP> kathy@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. If you are running programs that are so big you >can only run one dbx at a time, I would look at the sizes of your swap >partitions and how much main memory you've got. (You didn't say exactly >why you could only run one at a time, but I assume it must be one of >these.) Usually, big symbol tables come from big programs, and big >programs have a tendency to eventually fill memory. > >=Spencer ({ihnp4,decvax}!utah-cs!thomas, thomas@utah-cs.ARPA) The real reason dbx needs so much memory is that its type information is encoded as strings, which it must turn into a symbol table. It avoids copying all the information in the string table (like variable names) by leaving the original string table lying around in memory. Sdb, on the other hand, basically uses the symbols read in from the symbol table in uninterpreted form - it doesn't copy everything. When debugging large programs the dominant factor in terms of space becomes the repeated copies of (mostly type) information from header files. (For "large program" think "vmunix", for example.) Swap space is irrelevant here; dbx on anything the size of vmunix will want to run in 6-8MB. At Tolerant we have reimplemented all the -g stuff so that dbx's use of the symbol table information can be disk-based (it doesn't have it all in memory). Also, the linker removes duplicate information. Doug Doucette (tolerant!doug@berkeley, ...!ucbvax!tolerant!doug)
ps@celerity.UUCP (Pat Shanahan) (03/12/86)
In article <1700@utah-gr.UUCP> thomas@utah-gr.UUCP (Spencer W. Thomas) writes: >In article <169@gsg.UUCP> kathy@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@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@nosc
ka@hropus.UUCP (Kenneth Almquist) (03/12/86)
>> 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. [Kathryn Smith] > > The reason for this is that dbx knows so much more about your program. > [Spencer W. Thomas] I don't think so. Sdb knows the types of all the variables in the pro- gram and the line numbers corresponding to various sections of object code. Sdb and dbx have different sets of commands (dbx has simple, "user friendly" commands while sdb has a larger and more cryptic command set), but the symbolic abilities of both debuggers are similar. Kenneth Almquist ihnp4!houxm!hropus!ka (official name) ihnp4!opus!ka (shorter path)
dlc@a.sei.cmu.edu (Daryl Clevenger) (03/17/86)
I know dbx seems to take longer to start up, and apparently its use with large scale software projects makes it prohibitive, I still like it a LOT more than sdb. The big plus is that it handles structures correctly, but there are others. As for the command set being more limited, I thought the same thing from typing help in dbx, but after looking at the manual entry, it seems the command set is actually more extensive. I admit there are bugs and problems (some of them in the manual entry), but I think it is a good try at writing a debugger that is easier to use and behaves as users expect.
feldman@ccvaxa.UUCP (03/21/86)
There are at least 3 VAX versions of dbx that I've seen: 4.2, a net.sources update to 4.2, and 4.3 beta. The 4.3 beta version is a cut above the others because it introduces real macros, not just keyword substitutions. In part this allows the user to overcome the most frustrating thing about dbx, namely the amount of typing necessary to do anything. Of course, it takes some forethought and experiance to set up useful macros, and they differ from task to task, but for a drawn out development cycle, I found that it is a great improvement over the earlier versions. I'm still disappointed that <CR> doesn't work as in adb. At least '.' works. For large debugees, the size of the symbol table is an annoyance. I've found that compiling just those files that are in doubt or under development with -g, and linking -g cuts the symbol table overhead a lot. You need to be aware that continuing or stepping such that control returns out into code without the -g symbols will cause dbx to lose its grip. But "stop in" someplace that has debugging symbols will usually be enough to get the job done. It would be nice if the rest of the world could benefit from Sun's work on their compilers that cuts the redundancy in the symbol table caused by common include files. Mike Feldman Gould Computer Systems, Urbana IL