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