Ping.
Thanks.
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
Strace-devel mailing list
Strac
Example usage:
gdbserver --once --multi :65432 & sleep 2 ; /work/scox/strace/mysrc/strace -G
localhost:65432 ~/src/hello.x
[1] 4979
Listening on port 65432
/work/scox/strace/mysrc/strace: -G is always multithreaded, implies -f
Remote debugging from host 127.0.0.1
Process /home/scox/src/hello.x cr
The last posted patch lost a printsiginfo patch that used macro tricks
to avoid that signal.h problem but I changed to use an opaque pointer
for next_event/dispatch_event to avoid the problem. It is assumed that
a gdbserver is running and the strace gdbserver backend communicates
with that, t
This is the latest version of the gdbserver backend patch. It is
rebased to master, supports the new event dispatch scheme,and has
changes including buffer handling improvements and a rewrite of
notification queue handling. It is a large patch but much of it is
boilerplate changes due to adding
I modified the gdbserver backend to use this dispatch patch mechanism
A backend struct dispatch table is defined through which all backend
specific functions are called. The default dispatch table is setup in init:
backend.cleanup = NULL;
backend.detach = NULL;
backend.end_init
This is an implementation of the previously mentioned backend dispatch
table idea. This patch isolates the backend specific functionality
by creating a dispatch table for backend specific entrypoints; which
can be overridden by the backend. Most of the dispatch entries default
to the cur
This is a proposal to facilitate more cleanly integrating a new
backend, e.g. the previously proposed gdbserver backend
https://sourceforge.net/p/strace/mailman/message/35672632/
This is a proposed patch to add a dispatch table for a new backend. The
idea is to add a dispatch table, a table
> I'm is in the process of reviewing/rewriting your patch. The main
> issue here is that it is a bit intrusive and does so in a
> backend-specific way. I already had an idea of introduction of
> backend-neutral layer, in order to support uprobes. for example, and
> your submission poked me again i
> I already had an idea of introduction of
> backend-neutral layer, in order to support uprobes. for example, and
> your submission poked me again in this direction. I'll try to provide
> a feedback with updated set of patches in a coming weeks, so it can
> become a part of 4.17 release. Is it ok
> I'll try to provide a feedback with updated set of patches in a coming weeks,
> so it can
> become a part of 4.17 release. Is it ok for you?
>
Thanks Eugene; that will be great, much appreciated.
--
Check out the vibra
On 02/10/2017 03:21 PM, Stan Cox wrote:
> Requesting comments on this patch, which adds support for the gdb
> remote serial protocol
Ping on the patch. Also, fixed a register pool issue, which was not allowing
for varying x8664 register pool
Add a test: gdbrsp.c and a test driver gdbrsp.test. The test checks if
gdbserver is available and if it supports syscall catching.
diff --git a/tests/Makefile.am b/../src/tests/Makefile.am
index 90b7bf3..2c059e4 100644
--- a/tests/Makefile.am
+++ b/../src/tests/Makefile.am
@@ -143,7 +143,6 @@
The gdbserver directory contains the gdbserver backend, which
communicates with gdbserver via the gdb remote protocol, e.g.
strace sends packet: $vCont;c (continue)
strace receives packet:
T05syscall_entry:16;06:b0e2ff7f;07:68e2ff7f;10:27a9b0f7ff7f;thread:p2162.2162;core:
Requesting comments on this patch, which adds support for the gdb
remote serial protocol, which is described further in "info gdb
'Remote Protocol' 'Packets'" This protocol connects to gdbserver,
which catches the syscalls and returns information about them, as well
as register and memory info, via
grind 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
This is an example that shows the back and forth interaction that is possible
between an strace aware gdbclient and the gdb remote protocol aware strace.
STRACE client
Process 10442 attached in non-stop mode
GDB client
(gdb) continue
Thread 2 "tstthreads1.x" hit Breakpoint 3, thread_worker_2 ()
I just made one small change. I didn't want to start using the
vContc;c:ppid.tid form until I saw the completed syscall where the tid
changed. For recent linux this is typically set_robust_list. So once
the syscall return is seen it starts using the pid.tid form. This was
already there in a
> It's still not clear to me what it means to "follow" syscalls for :2.
> Is that copying the syscall watchlist to the child?
es the default?
It was an attempt to mimic this behavior by filtering the tids and
syscalls in gdb_catch_this_syscall_p.
/usr/bin/strace -f tstthreads.x
...
mprotect(0x7
> Can you explain your -f changes?
>
> I see you're alternating QCatchSyscalls:1 or QCatchSyscalls:2 -- what
> are these values? Has this protocol change gone into gdb upstream, or
> just your own gdb branch?
Yes, it was just a local change. QCatchSyscalls:1 was without -f being
specified and Q
> Additionally, support for qualifying expressions (-e expr) and following
> children (-f) will be pushed soon.
-f and -e support has been added to the gdbserver remote protocol backend in
the strace branch at https://github.com:stanfordcox/strace
Here is an interleaved example with two threads.
This is a followup to
https://sourceforge.net/p/strace/mailman/message/34782296/
which describes Josh Stone's work on strace support for the gdb remote
protocol.
https://github.com/cuviper/strace/
Initially this effort supported gdbserver "all stop" mechanism, which
stops all threads. Suppo
21 matches
Mail list logo
