Assume that we have a single thread program and we hope to capture the value of program counter (PC) when a predefined interrupt occurs (like a timer interrupt).
It seems easy as you know we just write a specific assembly code using a special keyword "__asm__" and pop the value on the top of the stack after making a shift 4 byte.
What about Multithreaded programs ?
How can we get values of all threads from another thread which run in the same process? (It seems extremely incredible to get values from thread which run on a separate core in multi-core processors).
(in multithreaded programs, every thread has its stack and registers too).
any help, I am grateful to you.
A more fundamental question is: why do you want to do this?
I sense that you are trying to gauge progress or status for each of the threads. However, in the implementation you are proposing, this is fraught with danger as either the program counter itself (which is not accessible without HW support and some kind) or some stored copy of the counter (say, taken at the last interrupt) are both not very effective for such a use. e.g. what if the other thread you are looking at happens to be in a common subroutine? (Which happens a lot. Surprisingly, most programs spend most of their time not in their own code.) Without some kind of call stack trace, what will that tell you?
If it is, indeed, "progress" or "status" that you are trying to detect, it would be more effective to have shared storage where each thread could periodically record its progress or status (e.g. at the top of each loop iteration, store your local progress counter into the shared storage). In that way, the interrupt monitoring thread could gather the best possible status current and do whatever is the desired action.
If it is program coverage testing that you are looking to implement, there is a tool that I am aware of called "Probe" which gathers "last interrupt program counter" information to do such a task. While this is pretty effective, there are problems that arise due to areas of code that mask off interrupts (e.g. critical sections). The counters gathered tend to have spurious clusters on the instruction that re-enables interrupts. But, still, you get some useful information.
So, why do you want to do this?
Oh yes. IN principle ...
Provided that one or more cores operate under a single operating system kernel, there exists a control structure for all cores/threads that in the end is memory-mapped - providing the possibility to read it.
Simple: no. To do so requires deepest insight into the OS structure, organization etc. It is unlikely that you can implement such things on proprietary OSes, though they might come with tools for such things. For open source OSes like Linux it should be doable - if nobody else did it. I'm not sure what keywords to search for, but something like "task monitor", "thread monitor" or alike might be able to produce links to existing solutions.
A more fundamental question is: why do you want to do this?
I sense that you are trying to gauge progress or status for each of the threads. However, in the implementation you are proposing, this is fraught with danger as either the program counter itself (which is not accessible without HW support and some kind) or some stored copy of the counter (say, taken at the last interrupt) are both not very effective for such a use. e.g. what if the other thread you are looking at happens to be in a common subroutine? (Which happens a lot. Surprisingly, most programs spend most of their time not in their own code.) Without some kind of call stack trace, what will that tell you?
If it is, indeed, "progress" or "status" that you are trying to detect, it would be more effective to have shared storage where each thread could periodically record its progress or status (e.g. at the top of each loop iteration, store your local progress counter into the shared storage). In that way, the interrupt monitoring thread could gather the best possible status current and do whatever is the desired action.
If it is program coverage testing that you are looking to implement, there is a tool that I am aware of called "Probe" which gathers "last interrupt program counter" information to do such a task. While this is pretty effective, there are problems that arise due to areas of code that mask off interrupts (e.g. critical sections). The counters gathered tend to have spurious clusters on the instruction that re-enables interrupts. But, still, you get some useful information.
So, why do you want to do this?
Thank you for all your assistance.
A more fundamental question is: why do you want to do this?
yes, let me ask again:
Can we read and fault-inject another thread's program counter?
As Mr. Peter Breuer mentioned, "So your question is about operating systems". Indeed, now I'm reading this book "Operating System Concepts (7th Edition), Silberschatz" to gain better understand about processes, threads and context switching peformed by operating system.
Through reading that I have made and discussion with some of Stackoveflow members, I see that we can do such work, But it will be very difficult.
actually, I would examine some of UNIX system calls (like Ptrace, and sending signals). But I do not know, Is it possible to solve this issue or not?
http://stackoverflow.com/questions/38018713/can-we-read-and-fault-inject-another-threads-program-counter
- Badges
- Science topic
- Similar topics
- Engineering
- Computer Engineering