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).

ref: http://sourceware.org/ml/archer/2009-q4/msg00064.html [read the full thread]

ref: http://sourceware.org/ml/archer/2009-q4/msg00089.html

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.

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

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

ref: http://sourceware.org/ml/archer/2010-q1/msg00086.html


OngoingWork

None: DebuggingLargePrograms (last edited 2013-09-27 21:09:19 by StanShebs)

All content (C) 2008 Free Software Foundation. For terms of use, redistribution, and modification, please see the WikiLicense page.