RFC strace via gdbserver

Stan Cox scox at redhat.com
Fri Feb 3 15:11:59 UTC 2017


I picked up Josh's work to support running strace over the gdb remote 
serial protocol.  Josh's last message is quoted below.

The gdb rsp support interfaces to gdbserver using the gdb rsp to run, 
attach, get registers, get memory, get syscall info

- https://github.com:stanfordcox/strace.git
- rebased to the latest development sources
- the strace gdb rsp interface now supports both gdb remote protocol
   (-G option) and standard ptrace protocol.
- added a test (gdbrsp.test); all tests passed
- tried it on ppc, a target that does not yet support the gdb rsp
   syscall interface;  all tests passed

> 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.
>
> 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.






More information about the Strace-devel mailing list