Using NDK r8c, Eclipse 4.2, Windows 7 64
I've used remote debuggers before (on other platforms, via gigabit ethernet) for large C++ codebases that felt no different than local debugging. The Java debugger that comes with the SDK runs fast too. Therefore I'm quite baffled why gdb is so slow to connect and step over lines of code.
In my current application, which is around 20 static libraries and 1500 source files, it takes about 15 seconds to connect, and about 2 seconds to step. I'm more concerned about stepping.
Has anyone ever profiled gdb to see what the problem is? If so, any suggestions?
I have. My cohorts and I at NVIDIA have contributed several commits to AOSP to address this problem, although our focus has been on shared libraries (symbol load performance, and pending symbol resolution.) We have sped up solib load processing by a factor of 6x. (Although, after doing our own work we discovered that 3x of that 6x had already been solved upstream by GNU, in 7.5... so we abandoned our reinvention, and submitted the relevant 7.5 patches up to Google's NDK repository, which was based on the older 7.3 GDB.) I believe all of our speedups are present in r8d... but I haven't checked.
I cannot think of any reason why static libraries would slow things down, but I must admit I haven't given any thought to them. Do you have a specific reason for believing so, or was that just comment to give perspective about the size and scope of your debugging needs?
We have begun to work on the stepping problem, but don't have anything to share yet. Basically, the bottleneck is ADB (especially on Windows.) Additionally, there is a lot of chatty communication between GDB and gdbserver, when stepping, especially if you are using an IDE with local window, register window, expression window, stack window, etc., all updating with each step. That's a lot of chatter that could likely be optimized for the IDE use-case.
Just some of the fixes that we are considering for speeding up stepping will be IDE-specific:
Using python scripting to pre-process watch expressions in GDB, rather than in the IDE.
Implementing "super-packets" communicating between GDB and gdbserver... packets that encapsulate IDE-specific communications in a way that minimizes chatter between GDB and gdbserver.
We intend to share all of this with the Android community.