On Thu, 11 Jul 2002, Kevin D. Kissell wrote: > In responding to an enquiry from one of MIPS' third-party > software vendors, I noted something that seems a little > broken to me in the current (and maybe all historical) > MIPS/Linux kernels. Please forgive me for opening > old wounds if this has been beaten to death in the past. :-/ > When a user catches a signal, such as SIGBUS, the > signal "payload" includes a pointer to a sigcontext > structure on the stack, containing the state of the > CPU when the exception associated with the signal > occurred. But not exactly. We seem to consistently > call compute_return_epc() before send_sig() or > force_sig(). This results in the user being passed > an indication of the faulting PC that is one instruction > past the true location. That would be no problem, > except that the faulting instruction may have been > in a branch delay slot, such that there is no practical > and reliable way for the signal handler to determine > which instruction failed on the basis of the sigcontext > data. That needs to be done globally, once and forever for all kinds of signals passed to a program. I have partial fixes that I am using privately already, but a complete solution is on my to-do list. > It is, of course, important that execution resume > at the instruction following any instruction generating > an exception/signal. But that's not the same thing > as saying that the sigcontext should report the resumption > EPC instead of the faulting EPC. There are various > ways of dealing with this, but before going into any > of them, I'm curious as to whether this has been > discussed before, and whether anyone thinks that > things really should be the way they are. I believe the resumption should happen with EPC unmodified. A handler may set EPC differently if it wants (possibly with longjmp() or by interpreting code at EPC and modifying EPC appropriately). For the three signal handling possibilities, I'd do that as follows (assuming SIGBUS, SIGSEGV, etc. lethal signals): - SIG_IGN: return to EPC with no action. A program will loop indefinitely, but if that's what a user wants... - SIG_DFL: kill. - HANDLER: call a handler with the signal context unmodified and let the user code decide what to do. Maciej -- + Maciej W. Rozycki, Technical University of Gdansk, Poland + +--------------------------------------------------------------+ + e-mail: macro@ds2.pg.gda.pl, PGP key available +
