Hello,
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 ;)
Regards
