IRC, freenode, #hurd, 2013-01-18
<braunr> youpi: what would you think of adding a debug-related syscall to
gnumach so that we have a printf-like tool even in situations where the
code can't perform an rpc (i.e. glibc)
<youpi> could be useful indeed
<youpi> I've found myself having a hard time making some printfs from odd
places of glibc :)
<braunr> i also suggest we make it unprivileged
<youpi> not enabled by default then
<youpi> otherwise it's an easy DoS
<braunr> well, for now, we don't care much about DoS, but we do care about
debugging
<braunr> at least until the very core issues we have are understood and
resolved
<youpi> I usually frown on debugging feature being too open
<braunr> me too
<youpi> you would always forget dropping one
<braunr> that's why i didn't suggest it earlier
<braunr> but i'm wasting too much time finding other decently effective
ways
IRC, freenode, #hurd, 2013-01-19
<braunr> youpi: how about we build this debugging system call in debugging
versions only ?
<braunr> i suppose you already use such versions for buildds anyway
<braunr> MACH_DEBUG is always enabled
<braunr> the debugging version only adds --enable-kdb if i'm right
<pinotree> check debian/rules
<braunr> that, and -fno-omit-frame-pointer
IRC, freenode, #hurd, 2013-01-21
<braunr> youpi: concerning gnumach, i've added a mach_print system call,
with one argument (a null terminated string) to -dbg kernels
(--enable-kbd)
<youpi> k
<braunr> if it's fine with you, i'll commit it too
<youpi> I'm fine
IRC, freenode, #hurd, 2013-04-07
<braunr> see http://www.sceen.net/~rbraun/mach_print/ for an example to use
it