RFC strace via gdbserver

[Josh Stone]

Hi folks,

Just wanted to give an update on this project, running strace over the
gdbserver protocol.  I've quoted my original message below, in case you
missed it the first time, and source is here:
  https://github.com/cuviper/strace/

The code has been rebased onto a much newer development branch, as of a
couple weeks ago.  I'll push new rebases occasionally to keep up.
There's still plenty of hacky/prototype hooks in place, so this isn't
ready for integration yet.  I need to address testing too.

Feature-wise, I've added file and piped-command support for gdbserver
communication, so you can connect in three ways:

 - tcp: strace -G host:port
 - file: strace -G /dev/ttyS0
 - piped-command: strace -G '|vgdb'

That last is how you can connect to a valgrind process.  Support for
QCatchSyscalls is now in valgrind trunk.  With this, you can strace a
process under valgrind without seeing the activity of valgrind itself!

GDB 7.11 was release in February, with support for QCatchSyscalls, so
new gdbserver builds will now have everything "strace -G" needs.

Stan Cox has started to get this working in gdbserver's non-stop mode.
Right now it runs all-stop, which means a multithreaded target will stop
every thread when any event is reported.  That's usually what you want
for an interactive debugger, but in strace it may cause a lot of
interrupted syscalls -- full of EINTR/EAGAIN/ERESTARTSYS.  So non-stop
will let other threads keep running freely while we process any event.

Dmitry pointed out -P and -y path-based options before, which I haven't
found a solution for.  Technically /proc/pid/fd access will work just
fine if the gdbserver is local anyway, but that's cheating, and can't be
assumed in general.  It may just be that some strace features won't be
able to mix with this -G gdbserver mode.

Anyway, work continues, and I hope people find this interesting.

Thanks,
Josh


On 01/20/2016 12:10 PM, Josh Stone wrote:
> Hi,
> 
> I've been experimenting with using strace via gdbserver, through the gdb
> remote protocol.  It's now in good enough state that I'd like to get
> some feedback.
> 
> First, syscall support in gdbserver is very new.  There was a patch
> posted a few years ago by Philippe Waroquiers, but I only just finished
> getting that merged last week.  This will be in GDB 7.11:
> https://sourceware.org/git/?p=binutils-gdb.git;a=commit;h=82075af2c14b1f8a54fa5796fb63f7ef23f98d9d
> 
> You can find my strace hacking at github.com/cuviper/strace/.  It adds a
> "-G host:port" option to point to a listening gdbserver.  However I've
> mostly just tested this on localhost so far, and surely cross-arch stuff
> won't work.
> 
> I'm not necessarily looking for a code review though, as I definitely
> took some prototyping shortcuts and this is not in merge-able state.
> Even the branch point from strace master is pretty old now -- I'm now
> working on rebasing that.  As RFCs go, I'm more looking for feedback on
> the concept.
> 
> Why would one want this?  At a first glance, I hope even just "remote
> strace" is interesting.  That isn't just over TCP as implemented now,
> but eventually any way that gdbserver can be reached, like serial
> debugging as it was originally started.  GDBserver is smaller than the
> strace binary too, so you could add just gdbserver on your remote hosts,
> containers, etc. to support both gdb and strace.
> 
> My colleague Stan Cox is also working on letting gdbserver work with
> multiple clients, even allowing them to independently attach to the same
> process.  So you can basically use this like a ptrace multiplexer,
> letting you use strace and gdb on the same process!
> https://sourceware.org/git/?p=archer.git;a=shortlog;h=refs/heads/scox/globalstate
> 
> He also has a dyninst branch, which means you could strace a process
> that's also being instrumented at the same time.
> https://sourceware.org/git/?p=archer.git;a=shortlog;h=refs/heads/scox/dyninst
> 
> 
> All feedback is welcome.  If you think this might be interesting enough
> to properly merge into strace, I'd especially appreciate guidance on how
> to best approach that.
> 
> Thanks!
> 
> Josh
>