Intel(R) Pentium(R) M processor 2.00GHz Linux does not differentiate between memory faults and privileged instruction faults. I am not sure if this is truly a bug, as it is more a matter of taste. However, I am currently developing a debugger with Linux as my primary platform, and i noticed that when a faulty program attempts to execute an instruction which is not allowed in ring3 (HLT for example), a SIGSEGV signal is produced. I found this to be unintuitive at best. My initial feeling would be that it would be more closely matched to the SIGILL (illegal instruction signal), even though that is for op-codes which are not legal in any context, it is a bit of a closer match to what is really happening. Obviously, in a perfect world, there would be a separate signal for this sort of situation, but I can see that being an issue with regard to backwards compatibility if any programs count on this behaviour. Like I said, it's arguable whether it's a bug at all, but I thought I'd at least mention it.
Evan, is the signal disposition still same? Maybe you can raise this question on the LKML, since it requires discussion. Thanks.
we always raised SIGSEGV on instructions that are "legal" but where sufficient permission is not present to execute them in the current context. SIGILL is for "invalid opcode" exception where the CPU says that it does not know the opcode at all. so this is not a bug nor an inconsistency in my opinion. Ingo
Memory fault and privileged instruction in user space are raising the same exception vector on x86 (idt 13 general protection fault), which makes sense as it protects against using privileged instructions from the wrong context. The general protection fault can have several dozen root causes (See Intel Software Deveopler manual Volume 3A, Chapter 5.15) and decoding it in the trap handler would be a horrible spaghetti code with no obvious benefit. Thanks, tglx
Thanks you. Closing the bug.