Exceptions: Difference between revisions
Yuron [PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs) m (1 revision imported) |
W81054ch [PHRhYmxlIGNsYXNzPSJ0d3BvcHVwIj48dHI+PHRkIGNsYXNzPSJ0d3BvcHVwLWVudHJ5dGl0bGUiPkdyb3Vwczo8L3RkPjx0ZD51c2VyPGJyIC8+YnVyZWF1Y3JhdDxiciAvPmludGVyZmFjZS1hZG1pbjxiciAvPnN5c29wPGJyIC8+PC90ZD48L3RyPjwvdGFibGU+] (talk | contribs) m (1 revision imported) |
||
(One intermediate revision by one other user not shown) | |||
Line 2: | Line 2: | ||
-->{{Path|Exceptions|1}}{{Path|OS Topics|6}}<!-- | -->{{Path|Exceptions|1}}{{Path|OS Topics|6}}<!-- | ||
-->{{#invoke:Dependencies|add|Concepts,3}} | -->{{#invoke:Dependencies|add|Concepts,3}} | ||
In general, in computing terms, “exceptions” are | In general, in computing terms, “exceptions” are circumstances which are outside the normal operations flow. For | ||
circumstances which are outside the normal operations flow. For | example, when accessing an array an exception could be caused if the index referred to an element beyond the size of that array. | ||
example, when accessing an array an exception could be caused if the | |||
index referred to an element beyond the size of that array. | |||
You may already be familiar with some classes of exceptions, e.g. from | You may already be familiar with some classes of exceptions, e.g. from Java. | ||
Java. | |||
<!-- | <!-- | ||
<span style=color:red> | <span style=color:red> | ||
Line 15: | Line 12: | ||
--> | --> | ||
The operating system software layer is also capable of generating | The operating system software layer is also capable of generating exceptions. You are probably already familiar with the <code>^C</code> method of terminating an application; note that there will usually not be an explicit check for this input in the application’s code. There is a further exploration of this principle in the [[Exercises:Exceptions|exercise on exceptions]]. | ||
exceptions. You are probably already familiar with the <code>^C</code> method of | |||
terminating an application; note that there will usually not be an | |||
explicit check for this input in the application’s code. | |||
There is a further exploration of this principle in the [[Exercises:Exceptions | exercise on | |||
exceptions]]. | |||
<em>Here</em> we are primarily concerned with exceptions which originate from | <em>Here</em> we are primarily concerned with exceptions which originate from <em>hardware</em> which are normally handled by the operating system. The sort of exceptions supported by particular hardware varies but here are some examples of exceptions at the hardware level. | ||
<em>hardware</em> which are normally handled by the operating system. The | |||
sort of exceptions supported by particular hardware varies but here | |||
are some examples of exceptions at the hardware level. | |||
* [[Reset]] – used to <em>start</em> a system in a well defined way | * [[Reset]] – used to <em>start</em> a system in a well defined way | ||
* [[ | * [[System Calls|System call]] | ||
* [[ | * [[Emulator Trap|Emulator trap]] | ||
* [[ | * [[Memory Fault|Memory fault]] | ||
* [[Interrupts | Interrupt]] | * [[Interrupts|Interrupt]] | ||
* [[ | * [[Processor Privilege|Privilege]] violation | ||
* Arithmetic error (e.g. division by zero, numeric overflow) | * Arithmetic error (e.g. division by zero, numeric overflow) | ||
* Debug breakpoint | * Debug breakpoint | ||
Line 48: | Line 37: | ||
=== Common features === | === Common features === | ||
The typical hardware exception is a high-priority event which is likely to take precedence over other tasks. Some are a result of a software action (e.g. a system call); some originate purely from hardware (e.g. an interrupt); some come from an interaction between hardware and software (e.g. a page fault). All have a certain | The typical hardware exception is a high-priority event which is likely to take precedence over other tasks. Some are a result of a software action (e.g. a system call); some originate purely from hardware (e.g. an interrupt); some come from an interaction between hardware and software (e.g. a page fault). All have a certain commonality in response. | ||
commonality in response. | |||
An exception acts as a ‘call’ to the processor, invoking a method/procedure/subroutine/whatever-you-call-it. The process of the call also raises the [[Processor_Privilege|privilege level]] of the processor so that it can legitimately interact with the hardware. This routine is entered at a well-defined address which is normally reserved for operating systems’ code and should have appropriate [[Memory_Protection|protection]] which stops user processes abusing the | An exception acts as a ‘call’ to the processor, invoking a method/procedure/subroutine/whatever-you-call-it. The process of the call also raises the [[Processor_Privilege|privilege level]] of the processor so that it can legitimately interact with the hardware. This routine is entered at a well-defined address which is normally reserved for operating systems’ code and should have appropriate [[Memory_Protection|protection]] which stops user processes abusing the facility. | ||
facility. | |||
Now running <em>trusted</em> code, the processor can determine more information about the cause of the exception. It takes appropriate remedial action. Depending on the particular circumstances it may be able to deal with the exception transparently, and return to the user code transparently, or it may decide that the issue cannot be ‘fixed’ and not return, instead, perhaps, scheduling some | Now running <em>trusted</em> code, the processor can determine more information about the cause of the exception. It takes appropriate remedial action. Depending on the particular circumstances it may be able to deal with the exception transparently, and return to the user code transparently, or it may decide that the issue cannot be ‘fixed’ and not return, instead, perhaps, scheduling some other action. | ||
other action. | |||
The detailed behaviour may need to be a software (O.S.) decision. For | The detailed behaviour may need to be a software (O.S.) decision. For example: | ||
example: | |||
*A memory fault caused by a ‘rogue’ pointer probably indicates a process has crashed (or is trying to do something illicit) and the guilty process will be exterminated.<br /> (E.g. “Segmentation fault”). | *A memory fault caused by a ‘rogue’ pointer probably indicates a process has crashed (or is trying to do something illicit) and the guilty process will be exterminated.<br /> (E.g. “Segmentation fault”). | ||
Line 64: | Line 49: | ||
*A memory fault used to track whether a page is still in use will simply note the status and return ‘immediately’.<br /> (Some systems do do this – but don’t worry if you don’t follow this last point.) | *A memory fault used to track whether a page is still in use will simply note the status and return ‘immediately’.<br /> (Some systems do do this – but don’t worry if you don’t follow this last point.) | ||
The exception handler might also send a [[Unix Signals|signal]] to | The exception handler might also send a [[Unix Signals|signal]] to communicate information back to a user process. A user process can sometimes <em>register</em> its own signal handlers for some exceptions. | ||
communicate information back to a user process. A user process can | |||
sometimes <em>register</em> its own signal handlers for some exceptions. | |||
<blockquote> | <blockquote> | ||
There is an [[Exercises:Exceptions|exercise]] for you to try this. | There is an [[Exercises:Exceptions|exercise]] for you to try this. | ||
Line 81: | Line 64: | ||
---- | ---- | ||
{{BookChapter|12.2.3|494-498}} | |||
{{PageGraph}} | {{PageGraph}} | ||
{{Category|Concepts}} | {{Category|Concepts}} |
Latest revision as of 10:02, 5 August 2019
On path: Exceptions | 1: Exceptions • 2: Reset • 3: System Calls • 4: Software Exceptions • 5: Emulator traps • 6: Memory Fault • 7: Interrupts • 8: Unix Signals |
---|
On path: OS Topics | 1: Concepts • 2: Cache • 3: Context • 4: Processor Privilege • 5: Process Scheduling • 6: Exceptions • 7: Interrupts • 8: Direct Memory Access (DMA) • 9: Virtualisation • 10: Hypervisor |
---|
Depends on | Concepts |
---|
In general, in computing terms, “exceptions” are circumstances which are outside the normal operations flow. For example, when accessing an array an exception could be caused if the index referred to an element beyond the size of that array.
You may already be familiar with some classes of exceptions, e.g. from Java.
The operating system software layer is also capable of generating exceptions. You are probably already familiar with the ^C
method of terminating an application; note that there will usually not be an explicit check for this input in the application’s code. There is a further exploration of this principle in the exercise on exceptions.
Here we are primarily concerned with exceptions which originate from hardware which are normally handled by the operating system. The sort of exceptions supported by particular hardware varies but here are some examples of exceptions at the hardware level.
- Reset – used to start a system in a well defined way
- System call
- Emulator trap
- Memory fault
- Interrupt
- Privilege violation
- Arithmetic error (e.g. division by zero, numeric overflow)
- Debug breakpoint
- …
Here is a (somewhat cryptic) list of x86 processor exceptions.
It is likely that all of the exceptions supported by a particular machine call into the operating system. For space reasons we only describe a selected, illustrative subset here; see the individual articles for more details.
Common features
The typical hardware exception is a high-priority event which is likely to take precedence over other tasks. Some are a result of a software action (e.g. a system call); some originate purely from hardware (e.g. an interrupt); some come from an interaction between hardware and software (e.g. a page fault). All have a certain commonality in response.
An exception acts as a ‘call’ to the processor, invoking a method/procedure/subroutine/whatever-you-call-it. The process of the call also raises the privilege level of the processor so that it can legitimately interact with the hardware. This routine is entered at a well-defined address which is normally reserved for operating systems’ code and should have appropriate protection which stops user processes abusing the facility.
Now running trusted code, the processor can determine more information about the cause of the exception. It takes appropriate remedial action. Depending on the particular circumstances it may be able to deal with the exception transparently, and return to the user code transparently, or it may decide that the issue cannot be ‘fixed’ and not return, instead, perhaps, scheduling some other action.
The detailed behaviour may need to be a software (O.S.) decision. For example:
- A memory fault caused by a ‘rogue’ pointer probably indicates a process has crashed (or is trying to do something illicit) and the guilty process will be exterminated.
(E.g. “Segmentation fault”). - A memory fault caused by a virtual memory page fault will normally cause some corrective action and the user process will be resumed sometime later.
(Other processes may be scheduled in between.) - A memory fault used to track whether a page is still in use will simply note the status and return ‘immediately’.
(Some systems do do this – but don’t worry if you don’t follow this last point.)
The exception handler might also send a signal to communicate information back to a user process. A user process can sometimes register its own signal handlers for some exceptions.
There is an exercise for you to try this.
Exact and Inexact Exceptions
Hardware exceptions may be broadly classed as being ‘exact’ or ‘inexact’, depending on the relationship of the cause to the place the software responds to them.
- Exact exceptions occur at a fixed position. The most obvious example is the system call which is an explicit instruction at a fixed place in the code. A less obvious example is the memory fault; however in a system using virtual memory it is important that the exception handler can identify exactly where the ‘fault’ occurred (e.g. within a sequence of
load
operations) so that it can identify the correct page … and return to rerun the operation. - Inexact exceptions are typified by interrupts and there is no way to predict when they might be serviced. The implication for operating system code is never to allow interrupts in an atomic sequence of instructions to prevent context switching etc. within the sequence.
Also refer to: | Operating System Concepts, 10th Edition: Chapter 12.2.3, pages 494-498 |
---|