> What is wrong putting a signal handler in your process for a signal,
> and busy wait in that signal all the time that you want?
The point is that I'm implementing a tool that shall test fault tolerance (in
the user processes, operating system, architecture, ...). The process is not
supposed to know that he is being delayed!
n0ano suggested me another solution (thanks n0ano!!!): instead of altering
the CS, I just put some code to the process stack, return to the SS:ESP
(instead of CS:EIP) and, later, restore the stack and return to the process.
This is not working yet because it's - I'm having some problems with it.
Could anyone look at this code and tell me where it can fail?
rdtsc
movl %eax, %ecx
addl $0x1, %ecx
loop:
rdtsc
cmp %ecx, %eax
jb loop
When I read the timestamp («rdtsc»), a value is returned to edx:eax. This
code works just fine when I put it in the process stack. The problem is when
I want to compare %edx instead of %eax, that is:
rdtsc
movl %edx, %ecx
addl $0x1, %ecx
loop:
rdtsc
cmp %ecx, %edx
jb loop
This is supposed to take much more time than the other loop. When I write
this code to the stack of my process, a segmentation fault occurs after some
time. Why? I'm not changing the stack at any moment! (By the way, the stack
pointer is pointing to the end of my code...)
-- Luís Henriques - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Fri Nov 23 2001 - 21:00:33 EST