diff options
Diffstat (limited to 'hurd/debugging')
| -rw-r--r-- | hurd/debugging/rpctrace.mdwn | 124 |
1 files changed, 122 insertions, 2 deletions
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. <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 + functional? + <teythoon> should be + <teythoon> well, you should be able to use it on any application that uses + select + <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 + functions + <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> + http://www.gnu.org/software/hurd/gnumach-doc/Syscall-Emulation.html + <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 + ipc + <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 + about + <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 + itself + <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 |