|author||Thomas Schwinge <firstname.lastname@example.org>||2014-02-26 12:32:06 +0100|
|committer||Thomas Schwinge <email@example.com>||2014-02-26 12:32:06 +0100|
Diffstat (limited to 'hurd/debugging/rpctrace.mdwn')
1 files changed, 122 insertions, 2 deletions
diff --git a/hurd/debugging/rpctrace.mdwn b/hurd/debugging/rpctrace.mdwn
index d62a4387..dbd4b30b 100644
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012, 2013 Free
-Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011, 2012, 2013, 2014
+Free Software Foundation, Inc."]]
[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -225,6 +225,126 @@ See `rpctrace --help` about how to use it.
<braunr> select is partially hand written
<braunr> but it's a special case so that's ok
+* IRC, freenode, #hurd, 2013-12-11
+ <gnu_srs> teythoon: Congrats regarding rpctrace, is it now fully
+ <teythoon> should be
+ <teythoon> well, you should be able to use it on any application that uses
+ <teythoon> other than that, it's as functional as it ever was
+ <teythoon> i was annoyed that i couldn't rpctrace ping, and the fix was
+ much easier than expected
+ <gnu_srs> and fork is no problem anymore?
+ <teythoon> was it ever ?
+ <braunr> yes, fork and some issues
+ <teythoon> rpctrace should pick up any forked processes
+ <teythoon> oh ?
+ <braunr> thanks for rpctrace too
+ <braunr> it was indeed on the todo list for a long time
+ <braunr> ah fork with regard to rpctrace
+ <braunr> no i don't think so
+ <braunr> but
+ <braunr> rpctrace can't be a perfect proxy
+ <braunr> because some calls just go directly through the kernel
+ <teythoon> really ?
+ <teythoon> we could install custom functions for any such call
+ <braunr> system calls
+ <braunr> yes
+ <teythoon> so why couldn't it be perfect ?
+ <braunr> i don't see how custom functions would do the trick
+ <braunr> i mean
+ <braunr> it would help, but not guarantee applications have to use these
+ <braunr> the real solution would be something like strace
+ <teythoon> huh ?
+ <teythoon> why wouldn't there be any guarantee like that ?
+ <braunr> rpctrace catches messages, not system calls
+ <braunr> you don't see calls to mach_reply_port() obviously
+ <braunr> you just hope that such reply ports are sent through messages
+ rpctrace will see
+ <teythoon> sure one does
+ <braunr> ah that
+ <braunr> we don't want that :p
+ <teythoon> why not ?
+ <braunr> it's a hack
+ <braunr> and checking for those impacts performances a bit
+ <braunr> it would be better to change the system calls into RPCs
+ <teythoon> so ? it would only affect tasks running in rpctrace, and the
+ documentation does not call that interface a hack ;)
+ <braunr> oh i agree
+ <braunr> i was saying we don't want them the same way we don't want async
+ <teythoon> yeah sure, i agree
+ <braunr> but since that's how mach works, why not
+ <braunr> although iirc, checking for emulated syscalls is done by the
+ syscall entry code
+ <teythoon> so ?
+ <braunr> so it has an impact on every system call
+ <teythoon> we could make that a compile time option and use it in rpctrace
+ only when available
+ <teythoon> so anyone who needs good traces, could run that kind of kernel
+ <braunr> no need
+ <teythoon> for what ?
+ <braunr> mach and the hurd are already too slow for this to be noticeable
+ <braunr> let's just live with it and use syscall emulation
+ <teythoon> why do you say that, i mean, do you have numbers ?
+ <braunr> from what i see, it's a bunch of less than 5 instructions
+ <teythoon> ok
+ <braunr> i'm just being picky
+ <braunr> i really don't like the idea of emulated system calls
+ <braunr> RPCs are much cleaner
+ <braunr> and frankly, the system calls that i'd like to see in rpctrace are
+ those like mach_thread_self()
+ <braunr> to spot reference leaks
+ <braunr> not too annoying actually
+* IRC, freenode, #hurd, 2013-12-13
+ <teythoon> hm
+ <teythoon> i briefly looked into the haskell test suite failure youpi wrote
+ <teythoon> i looked at one of the haskell-http-conduit failures
+ <teythoon> i think it starts a dummy web server and does one request to
+ <teythoon> the binary is using select, so i used the fixed rpctrace to
+ obtain a trace
+ <teythoon> it looks strange ...
+ <teythoon> the http request is answered before the request is sent
+ <gnu_srs> teythoon: Nice to see that you added escape of non-printable
+ characters in rpctrace:-D
+ <teythoon> yeah, makes rpctrace less trippy though ;)
+* IRC, OFTC, #debian-hurd, 2014-02-20
+ * pere really misses strace.
+ <pere> rpctrace is not even close.
+ <teythoon> pere: why do you say that ?
+ <teythoon> pere: it is not that we couldn't write strace for mach, it
+ would just be very boring
+ <pere> teythoon: because strace tell me what a program does in details,
+ without too much irrelevant information, while rpctrace is just so
+ verbose that it is hard to see the relevant parts.
+ <youpi> well, they are mostly equivalent
+ <youpi> strace ls / gives me 200 lines, while rpctrace ls / gives me
+ 300 lines
+ <youpi> there are spurious lines like term_getctty, but otherwise it's
+ mostly the same level of details
+ <youpi> (also, mach_port_deallocate get in the way)
+ <pere> strace also have the great advantage for C programmers that the
+ output look like the equivalent C calls.
+ <youpi> well, twice as many lines is not so much more verbose :)
+ <youpi> but yes, having internal RPC names doesn't help
+ <youpi> another way would be to use sotruss
+ <pere> sotruss just gave me 'killed'
+ <youpi> yes, it probably needs fixing, nobody worked on it AFAIK
+ <youpi> that's why I said "would", not "is" :)
+ <pere> in the mean time, I'll just keep dreaming of something with
+ output like strace. :)
# See Also