I have found the root cause of this problem:
It doesn't matter if the gdb is compiled with sbuild, debuild or dpkg-buildpackage. It's slow, because it reads BFDs from a *hidden* directory "/usr/lib/debug/.build-id/" The gdb compiled using "configure" script had different prefix, so its "relocatable" paths were pointing to an empty "debug" directory - that's why it was "fast".

But, this is not the end of problems:
When the gdb is started, it reads symbols from target program and from libraries which are loaded by the target program. In my test case (2.5MiB executable with debug symbols included + wxWidgets library with dbgsym package installed) the symbol table size is ~8MiB, and the gdb process is using ~50MiB. This is sufficient to debug the program, but after issuing the "run" command, the BFDs from "/usr/lib/debug/.build-id/" are read - and gdb creates a Monster Symbol Table with size over 200MiB (~280Mib used in total). Then things are getting only worse - any gdb command for displaying type or value of target program' variables causes the the memory consumption to double, in my case from ~280MiB to ~570MiB and the response times become deadly slow.

But, this is not the end of problems: (2)
In all test cases the gdb was compiled with --enable-threading - and indeed, gdb creates (num_CPU +1) threads on startup (in my case it's 17 for 16-core CPU). But the threading support in gdb is an illusion - those additional threads are *never* used, with a single exception - they are used only after the "run" command is issued, probably to read the BFDs. For any other gdb command only the main thread is consuming CPU time.

I thought that this BUG should be easy to eliminate - but it turns out that there are several serious BUGs in the gdb, and the only way to eliminate them is to debug the gdb first ;)


Reply via email to