4 ms·

The Unix side of this comparison is talking about signals, but what is the ITS side talking about? A technical description of that is available at [0]. >Anothe

by wrs 7y ago

The Unix side of this comparison is talking about signals, but what is the ITS side talking about? A technical description of that is available at [0]. >Another way to state the PCLSRing modularity principle is to say that when a process looks at the program counter of another process, it must always see a User mode PC, never an Exec mode PC. When one process wants to access the state of another process, and the target process happens to be executing in Exec mode, then something must be done in order to put the target process into User mode. [0] https://hack.org/mc/texts/pclsr.txt https://hack.org/mc/texts/pclsr.txt

comex 7y ago
And to complete the circle, the Unix way for one process to look at another’s program counter, ptrace(), works via signals. I recently had to implement a version of that behavior when writing a GDB stub for an embedded microkernel. The system in question originally had neither a debugger nor an equivalent of signals, or any other way for system calls (message sends and receives) to be interrupted – so the programs written for it naturally assumed they wouldn’t be, and didn’t have any code to retry interrupted operations. I could have gone through and changed those programs, but it would have been a lot of work and easy to get wrong. Instead, just as described in that link, I had the GDB stub set the PC to point back to the system call instruction, so it would be restarted after continuing the thread, and adjust the argument registers if necessary (e.g. if a combined message send+receive operation was interrupted after the send but before the receive, the arguments had to be changed to request only a receive). This was made more difficult by the fact that the microkernel originally threw away some of those register values, in the name of efficiency, assuming they wouldn’t be needed once the system call had started…

by wrs 7y ago

comex 7y ago

And to complete the circle, the Unix way for one process to look at another’s program counter, ptrace(), works via signals. I recently had to implement a version of that behavior when writing a GDB stub for an embedded microkernel. The system in question originally had neither a debugger nor an equivalent of signals, or any other way for system calls (message sends and receives) to be interrupted – so the programs written for it naturally assumed they wouldn’t be, and didn’t have any code to retry interrupted operations. I could have gone through and changed those programs, but it would have been a lot of work and easy to get wrong. Instead, just as described in that link, I had the GDB stub set the PC to point back to the system call instruction, so it would be restarted after continuing the thread, and adjust the argument registers if necessary (e.g. if a combined message send+receive operation was interrupted after the send but before the receive, the arguments had to be changed to request only a receive). This was made more difficult by the fact that the microkernel originally threw away some of those register values, in the name of efficiency, assuming they wouldn’t be needed once the system call had started…