On Thu, Nov 21, 2002 at 01:33:07PM -0000, atul srivastava wrote: > 2.but immediately after sys_execve returns the value, i get a > sudden page fault producing a imposible register dump ( epc status > and cause all zero) Check the cache and TLB code for your architecture. Read it 10 times if necessary because bugs in that code can have extremly subtle effects. > though i haven't read fully the gcc info page and acquanited with > nasty asm code of _syscall3 in unistd.h , but does execve enters > sys_execve directly by macro expansion in _syscall3 ..or there are > relevant steps in between.? I recommend to not use the _syscall macros in userspace _at_all. They've been written for use by kernelspace; getting them bullet proof for userspace as well has been a big pain over the years. I know, you're doing this for testing only but even then you're not safe ... In general the use of all kernel header files for userspace applications is a dangerous idea ... > what kind of problem i am facing ? > is this problem with saving & restoring , corruption > or in _syscall3..? _syscallX() is pure userspace stuff. Any bugs in that area should only result in your process but not the entire system crashing. > any possibility of write buffer and pipeline hazard..? Write buffer stuff is only relevant for dealing with external agents that is SMP or I/O which doesn't seem related to your case. Double check the cache code for your CPU. There are lots of creative implementations of caches out there that need special treatment in the kernel. (That was the political correct version of speaking about those cache designs. My prefered wording about this issue can't be posted in any public forum ;-) > I have tried with interrupts disabled in sys_execve just for > checking prupose.. > would taking support of BDI2000 kind of debuggers will be > helpful? The Linux/MIPS kernel has been ported and debugged entirely using printk and even more important by just look at the source. Ralf
