DebuggingLargePrograms
This page describes the work to speed up the debugging of large programs, and especially the start-up time.
Debugging large programs is excessively cumbersome in part because of all the debug info that needs to be read. GDB tries to optimize reading the info, but it's current method hasn't scaled well.
A lot of this work as been done by Tom Tromey, and has been implemented on ProjectArcher branches.
Build an index to assist reading DWARF CUs
One of the things that has been tried is building an index to assist reading DWARF CUs. Often when GDB needs debug info it reads too much, but it has no way of knowing where the info it needs is so it has to read all of it. This is especially true for name-based lookups. For pc-based lookups the .debug_aranges section helps.
ref: http://sourceware.org/ml/gdb-patches/2010-05/msg00583.html
ref: http://sourceware.org/ml/archer/2010-q2/msg00032.html
Read debug info in a background thread
Another thing that has been tried to improve the startup time is to read debug info in a background thread. The thought being that the user won't need the info right away so gdb can be busy reading it in and hopefully it will be available when it ultimately is needed.
ref: http://sourceware.org/ml/gdb-patches/2010-05/msg00583.html
Other things that have been tried
These things have also been tried, but have not yielded good results (thus far).
- .debug_pub{names,types} were intended to provide efficient name-based lookups are unsuitable for a few reasons.
ref: http://sourceware.org/ml/archer/2009-q4/msg00064.html [read the full thread]
- a custom section like .debug_pub*, but with exactly what gdb needed.
ref: http://sourceware.org/ml/archer/2009-q4/msg00089.html
- an SQLite database for the index
The big problem with reading psymtabs is accessing the disk. For best results, just don't do it at all. That is how the index scheme came to be, where the index is directly mmap()able and requires no further processing at startup time.
- more fine grained debug info.
E.g., instead of reading a whole CU, be able to read only part of it. Tom researched this and it appeared that reading the whole CU is not a bottleneck (actually, it turns out that there are some CUs which cause trouble...)
ref: http://sourceware.org/ml/archer/2009-q4/msg00091.html
Other things that have been thought of, but not fully investigated
- have gcc emit a special section and then changing the linker to turn it into a mappable index.
This would slow down the link and may be unacceptable. Also, we'd have to handle C++ name canonicalization somewhere in there, which adds more pain. See DebugFission
- C++ name canonicalization (apparently) costs a lot.
ref: http://sourceware.org/ml/archer/2010-q1/msg00086.html
- Lazily expansion of a symtab. Rather than have two readers (psymtab and symtab) in dwarf2read.c, have a single reader that reads a symtab. However, instead of reading full symbols, it would read something smaller, more akin to psymbols. Then, when searching a symtab, if a full symbol is needed, symtab.c would call into dwarf2read.c to expand just that one symbol. The primary difficulty here, aside from the amount of work involved, is that symbols are much larger than psymbols; but with some tricks this problem can be surmounted.
- Have a remote debug server and change gdb to make database queries.