I get: 1m35.685s: scp upload. 1m31.144s: gdbserver with gdb LINE_SIZE_POWER == 12 (0x1000). 3m55.867s: gdbserver with gdb default LINE_SIZE_POWER == 6 ( 0x40).
Just I guess usually people have lower RTT and lower uplink, don't they? In such case the results would be much more in the favor of gdbserver.
The numbers and the idea look promising. Thank you.
I'm working on a client uploading the whole coredump now. Both the retrace client and server can be later extended to support gdbserver to see what it's worth. We are currently ~2 months from satisfactory but mostly unoptimized solution, so I added the gdbserver possibility to the "Future work" section of the documentation for now.
Still in none of the cases it completes in 60 seconds after which you kill current GDB. So you are going to be killing even the upload processes.
60 seconds is to generate a backtrace from a coredump. Much more time is usually needed to download and extract debuginfos.
- Currently threading is not supported.
- Currently only x86_64 is supported (the NOTE registers layout).
I can finish the two missing features if there is an interest in it.
Wouldn't it make sense to merge your gdbserver code to GDB's gdbserver?
Karel