I saw the ramfs forks and execs 9pserve, that's why I tried gdb on the 9pserve process, not in ramfs. But I could not understand the makecontext() kind of context switching of libpthread used in 9pserve.
I'd have used 'acid', but I understand that it still doesn't allow breakpoints on Linux, and I don't know how to inspect many things with it. I can barely type a lstk(). :) I'd appreciate a "gdb to acid" mapping tutorial, for example. I guess most of the power of acid comes from acid-programs, which many people may have in their $home. :) Thanks, Lluís. 2008/2/7, sqweek <[EMAIL PROTECTED]>: > On Feb 7, 2008 7:22 AM, Lluís Batlle <[EMAIL PROTECTED]> wrote: > > Hello Russ, > > > > before trying to code something from scrach using createfile & co., I > > wanted to get ramfs working (that of lib9p/, the only example of > > Tree/File I found in plan9port). After your fix related to a proper > > unmount/remount, now I see that the 9pserve process exits hardly if I > > try to create a file in the ramfs filesystem. It doesn't die because > > of a signal. I tried gdb on it, breakpointing at exits/threadexits, > > but I don't understand the makecontext() game of libthread. I put a > > stderr trace in the fscreate() function of ramfs.c, and it doesn't > > even appear. I guess fscreate() is not called. > > libthread in p9p forks. By default, gdb follows the parent process, > which for libthread is not what you're interested in. Try: > > (gdb) break fscreate > (gdb) set follow-fork-mode child > (gdb) run > > Oh wait, I see now you put a print in fscreate(). Well, maybe this is > a useful tip anyway :) > -sqweek >
