GDB Adds Multi-Threaded Symbol Loading For Faster Debugging Performance

[phoronix]

Phoronix: GDB Adds Multi-Threaded Symbol Loading For Faster Debugging Performance

It's not often there are features to report on with regard to GNU Debugger (GDB) performance, but a new feature in place is multi-threaded symbol loading...

http://www.phoronix.com/scan.php?pag...hreaded-Symbol

[atomsymbol]

• It seems that gdb 8.3.1 is always demangling all symbols every time the "run" command is issued. One question is why to demangle C++ symbols that aren't going to be printed nor are being used in code completion.
• An option is to move the work to a background thread that doesn't block the "run" command.

[coder]

• It seems that gdb 8.3.1 is always demangling all symbols every time the "run" command is issued. One question is why to demangle C++ symbols that aren't going to be printed nor are being used in code completion.

If you reference any symbol prior to running (e.g. when setting a breakpoint), then it would need to parse them to know which you mean. Otherwise, as you say, it can just defer demangling until actually needed. And shouldn't have to demangle all symbols if you just print a backtrace - only those in the current call stack.

• An option is to move the work to a background thread that doesn't block the "run" command.

It'd be better not to. You want the debugger to have the minimum possible impact on program execution, and doing a bunch of work in other threads would certainly affect that. Even if you "nice" them, it could still frustrate attempts to reproduce certain race conditions or timing-sensitive behaviors in the debugger.

[discordian]

• It seems that gdb 8.3.1 is always demangling all symbols every time the "run" command is issued. One question is why to demangle C++ symbols that aren't going to be printed nor are being used in code completion.
• An option is to move the work to a background thread that doesn't block the "run" command.

how do you know which ones are used for code completion (match prefix) and breakpoints (match suffix)?
Also, is demangling really that expensive? I think parsing dwarf and creating structures for fast lookup is the main issue. You can also do this preprocessing once and add the "gdb index" to the debug-info (man gdb-add-index).
Should help alot for stuff like Qt.

[atomsymbol]

It'd be better not to. You want the debugger to have the minimum possible impact on program execution, and doing a bunch of work in other threads would certainly affect that. Even if you "nice" them, it could still frustrate attempts to reproduce certain race conditions or timing-sensitive behaviors in the debugger.

You are right. On the other hand, if the CPU has multiple cores (=N) and the program being run in gdb does not create more than N-1 threads than using 1 thread to perform initialization of gdb's internal data structures should be fine even in case of debugging race conditions or timing-sensitive behaviors. On hyper-threaded CPUs, with K threads per core, the limit would be N-K instead of N-1.

[atomsymbol]

how do you know which ones are used for code completion (match prefix) and breakpoints (match suffix)?
Also, is demangling really that expensive? I think parsing dwarf and creating structures for fast lookup is the main issue. You can also do this preprocessing once and add the "gdb index" to the debug-info (man gdb-add-index).
Should help alot for stuff like Qt.

gdb-add-index indeed helps to reduce gdb startup time (in the particular case I tested it with) by about 75% and initial memory consumption by about 65%.

In terms of C++ name demangling, the function "cplus_demangle" takes the same amount of time regardless of whether there is .gdb_index section in the executable/library. In case .gdb_index is present, "cplus_demangle" consumes about 50% of total initialization time. Without .gdb_index, the ratio is smaller than 50% (for example: 11%).

[discordian]

In terms of C++ name demangling, the function "cplus_demangle" takes the same amount of time regardless of whether there is .gdb_index section in the executable/library. In case .gdb_index is present, "cplus_demangle" consumes about 50% of total initialization time. Without .gdb_index, the ratio is smaller than 50% (for example: 11%).

Is that example measured or guessed?

Anyway I am still not sure how you would load/demangle symbols lazy. As soon as you have a single breakpoint or have to match code completion you have to search in all (demangled) symbols for a match?
Would then everything stop for some seconds the first time you hit tab?

That all sounds like alot of complications for speeding up launch. Not to mention that background jobs always affect runtime, even if you have enough cores available (locks, memory, an app enumering its own threads, etc.). Would probably be a easier with remote sessions.

[atomsymbol]

Is that example measured or guessed?

Measured. But it is a particular shared C++ library, other shared libraries might have different gdb initialization performance.

[coder]

Anyway I am still not sure how you would load/demangle symbols lazy. As soon as you have a single breakpoint or have to match code completion you have to search in all (demangled) symbols for a match?

If you already know which symbol(s) you want to demangle, then you can be very selective. So, in the case where program execution is interrupted and you want to generate a backtrace, you only have to demangle those specific symbols. However, you must've already parsed the entire symbol table, in order to resolve those addresses to symbols.

It's when you accept user input of symbols that you potentially need demangling.

Would then everything stop for some seconds the first time you hit tab?

Not only for completions, but potentially parsing any expression that can contain a symbol reference.

That all sounds like alot of complications for speeding up launch. Not to mention that background jobs always affect runtime, even if you have enough cores available (locks, memory, an app enumering its own threads, etc.).

Yeah, I'd just prefer to entirely avoid background threads while the program is actually running.