bothner@WSL.DEC.COM (04/18/89)
This is a discussion on improving gdb, rather than a bug report. To reduce the start-up time of gdb, there seems to be some hack to do "lazy" reading of symbols. I'm not sure this is a win, because whenever I do a "bt" I get very annoying pauses (when debugging a large program, such as an X server). These unpredicatable pauses detract very strongly from the user interface. There is an alternative: Using gcc's "-gg" flags, which writes out symbols in gdb internal format. The main problem (besides the extra non-standard magic needed in gas, ld, and gdb) is that gdb symbols are rather large. The solution is not to give up on gdbsyms, but to make the gdb symbol tables more compact. The information in a gdb symbol segment is of three main kinds: - Symbol names. It is hard to make these more compact, and standard dbx symbols are no more compact anyway. It may be possible to win some by avoiding duplicate strings; I don't know how worthwhile or hard this would be. Some more space might be saved by only padding to long boundaries when needed. - Line number information. Gdb symbols are already more compact than dbx symbols. However, the space needed could be halved by using shorts instead of longs. The machine code addresses would have to be relative instead of absolute. Changing this part would most affect the assembler, so I would leave it alone for now. - Tables of pointers, integers, and flags. This is where a lot of space can be saved. Most of these fields are 32 bits, where 16 bits is plenty for almost all cases. Suggestions: - All pointers to data structures within the symbol segment (such as pointers to strings, or types) are replaced by a 16-bit relative displacement. (An exception might be made for certain global structures and tables, such as the type vector). One of the 16 bits is reserved as an overflow flag, which is used to indicate an extra level indirection for the very few cases where the displacement won't fit in 16 bits: If the overflow flag is on, the displacement indicates a 32-bit (absolute or relative ?) pointer to the real data. - Using relative displacements means that gdb internally uses relative pointers. Dereferencing a pointer becomes somewhwt slower, but I cannot imagine a significant effect. Gdb no longer would relocate a segment on startup. This would save some startup time. In addition less data would need to be read from disk, and less memory would be used. Because the symbol segment is read-only, a system with mappable files need only map the segment into virtual memory, without having to actually read it. - Similarly, all (or most) integer, enum, and flag fields can be made 16 bits (or less). For integers that can occasionally (though infrequently) need more than 16 bits, I again suggest reserving one bit as an overflow bit, to indicate a pointer to a 32-bit value. Another potential win is to reduce the duplication of symbols because many files include the same include files. That is best done within the context of a module-oriented system, which requires a fairly major change in philosphy from the C way of doing separate compilation. Unfortunately, I cannot volunteer to do the work, so I guess I don't deserver much say into the matter... --Per Bothner Western Software Lab, Digital Equipment, 100 Hamilton Ave, Palo Alto CA 94301 bothner@wsl.dec.com ...!decwrl!bothner
tiemann@YAHI.STANFORD.EDU (Michael Tiemann) (04/18/89)
I think a better way is to make GDB read symbols in in the background. When the user strikes a key, gdb suspends what it was doing, services the request, and continues. I usually need a only very small amount of context to find my bugs, so lazy reading is a win. But it would be nice if, when I am doing nothing but staring at code, gdb could be anticipating my moves. I think that stabs have features which make them more attractive than symbol-table information conveyed by -gg. Namely, it is relatively easy to extend stabs, but painful to extend GDB's internal format. Michael
bothner@WSL.DEC.COM (04/18/89)
Lazy reading of symbols is a very neat idea, but the way it works
(at least in 3.1.2) contrary to everything the user interface
issue people have discovered. Slow response time is bad, but
what riles users even more is wildly varying response time.
Slow start-up is annoying, but one can do something else (read
news) while waiting. If individual commands are unpredictably
slow, it is much harder to do something productive while waiting.
It is not just "bt"; even more annoying is "next": I'm stepping
through a function, and everything is zipping along, and then
I call a function in a file whose symbols haven't been read yet.
Bam! I'm dead. It takes what seems like an eternity. I give up
and type ^C, thinking gdb is running wild. Etc.
I am not a naive user. I have ported gdb to a very different
platform (the V operating system - messages and no ptrace).
In spite of this, I thought the slow-ness of next was because it
was broken. I hacked our linker, debugged gas, and got gdbsyms
to work there. I thought the gdb symsegs worked great. I agree
they are too large, but that can be fixed.
Lazy reading of symbols is a great experiment. But, unless
worst-case pauses can be cut by a factor of 10, gdb is going
to be much less pleasant on large programs than it should be.
--Per Bothner
Western Software Lab, Digital Equipment, 100 Hamilton Ave, Palo Alto CA 94301
bothner@wsl.dec.com ...!decwrl!bothnerchrisb@mipon2.intel.com (Chris Benenati) (04/19/89)
In article <8904180616.AA13236@gilroy.pa.dec.com> bothner@WSL.DEC.COM writes: >I am not a naive user. I have ported gdb to a very different >platform (the V operating system - messages and no ptrace). >In spite of this, I thought the slow-ness of next was because it >was broken. Are you sure its the symbol reading that's taking the time? If your "very different platform" happens to involve a target remote system over a serial line, performing a C-level "next" can take a LONG time because gdb will start, stop, and read/write registers to/from the target after EVERY machine instruction.
bothner@decwrl.dec.com (Per Bothner) (04/21/89)
>In article <8904180616.AA13236@gilroy.pa.dec.com> bothner@WSL.DEC.COM writes: >I have ported gdb to a very different platform ... In spite of this, >I thought the slow-ness of next was because it was broken. Sorry for muddying my message with irrelevant points. I'm currently running under VAX Ultrix, not the "different platform". In article <4322@omepd.UUCP> chrisb@mipon2.UUCP (Chris Benenati) writes: >Are you sure its the symbol reading that's taking the time? Note I said the slowness is when stepping over a procedure. Normal "in-line" nexts are fast. Reading the symbol-table is definitely the culprit. -- --Per Bothner Western Software Lab, Digital Equipment, 100 Hamilton Ave, Palo Alto CA 94301 bothner@wsl.dec.com ...!decwrl!bothner