GB2380831A

GB2380831A - Debug exception handler and registers

Info

Publication number: GB2380831A
Application number: GB0204499A
Authority: GB
Inventors: Nigel Peter Topham
Original assignee: Siroyan Ltd
Current assignee: Siroyan Ltd
Priority date: 2001-10-12
Filing date: 2002-02-26
Publication date: 2003-04-16
Also published as: GB0124563D0; GB0204499D0

Abstract

A processor is disclosed which comprises a debug handler (3, fig. 1) for handling a plurality of debug related events occurring within the processor (1, fig. 1). A debug flag B is provided which can be set to enable a debug process, or cleared to disable it, and provides a simple mechanism for debugging a single process in a multi-thread environment. The debug flag may be cleared if an exception is raised as a consequence of a debug event and so may be used to enable the debugging of exception handlers. The debug flag may be part of a control register, and the processor may comprise a three level stack (figs. 3 and 4) for storing processor events when an exception is raised.

Description

DEBUG EXCEPTION REGISTERS The present invention relates to debugging of processors. The present invention has particular application in the debugging of embedded code. The present invention may be used, for example, in the debugging of exception handlers.

In an embedded processor it is common for the debug software to reside mostly on an external computer (known as the host), with a small debug handler (the debug kernel) running on the embedded processor (known as the target). The debug kernel communicates with the host debug software to provide the services needed by the host to gain access to the state of the processor and to set up the hardware within the target processor to perform debugging functions. The hardware of the target processor is designed so that, whenever an event of interest to the debugger occurs, an exception is raised. Debug status registers are set to indicate the type of debug event that occurred so that the debug kernel can inform the host of the event which occurred.

The host may ask the debug kernel to run a short fragment of code, or to read or write a value to a register within the processor or to a memory location to which the processor has access. Such debug related events are implemented through the processor's normal exception handling mechanism.

If the target processor supports a multi-thread environment, then it may be required to debug a single process (thread), or a subset of the total number of processes executing on the processor. However, this may require a complicated mechanism to ensure that debug exceptions are only raised during certain processes. Furthermore, if two processes access the

same addresses, then problems of processor state corruption may occur if one of those processes is being debugged. Processor state corruption may also occur where exception handlers are themselves debugged using the exception handling mechanism.

According to a first aspect of the present invention there is provided a processor comprising: a debug handler for handling a plurality of debug related events occurring within the processor; and a debug flag for enabling and disabling the plurality of debug related events.

The present invention may allow all debug related events to be disabled in certain circumstances, and then later re-enabled. This may provide a simple mechanism for debugging a single process in a multithread environment. If an address is commonly referenced by two or more processes, then the present invention may help the debug mechanism to be threadsafe (i. e. both processes may access the common address without corrupting the processor context). The present invention may also facilitate the debugging of exception handlers.

Preferably, the debug flag is set while a process which is to be debugged is being executed, and cleared while a process or a piece of code which is not to be debugged is being executed.

In a preferred implementation of the present invention, the debug flag is cleared if an exception is raised as a consequence of a debug event. In this way, further debug related events are disabled when the handler of the debug related event which caused the exception is entered. This mechanism may be a convenient way of

ensuring that the debug handler is not itself the subject of further debug related events. This mechanism may also be used to enable the debugging of exception handlers.

This important feature of the invention may also be provided independently. Thus, according to a second aspect of the present invention, which is linked to the first aspect by the unifying concept of a debug flag for enabling/disabling debug related exceptions, there is provided a processor comprising: means for storing a debug flag; means for raising an exception when a debug related event occurs and the debug flag is set; and means for clearing the debug flag if an exception is raised as a consequence of a debug event.

Preferably, the debug flag is not cleared if an exception is raised by an event other than a debug event. This may facilitate the debugging of exception handlers.

The debug flag is preferably a part of the processor's context which is automatically saved when an exception is raised. Thus the debug flag may be copied to a storage location (such as a register or a memory location) when an exception is raised. This may provide a convenient mechanism for saving the processor's debug status so that it can be restored when the processor returns to the process that raised the exception.

The debug flag may be part of a control register, in which case the contents of the control register may be copied to a storage location when an exception is raised.

The processor may comprise a multi-level stack (for example, a three-level stack) for storing processor context when an exception is raised. This can enable two or more levels of exception handling to be tolerated, which can allow an exception handler to be debugged without the context of a user program which caused the exception from being lost.

The processor may be arranged such that the or a debug handler is able to read to and/or to write from at least two levels of the multi-level stack, and preferably all levels. This can-allow the debug handler to set up the context which is stored in the stack to enable debugging of an exception handler.

Preferably the processor is arranged to enter the or a debug handler when an exception is raised due to a debug related event. Such debug related events may comprise at least one of a breakpoint event, a single step event, a change in operating mode event, a nonsequential execution event (such as a conditional branch, an unconditional branch, a subroutine call or return, a system call or an interrupt), or a CPU event (such as retiring of an instruction, a cache hit, a cache miss, a translation lookaside buffer (TLB) hit, a TLB miss, or a pipeline stall).

The processor may be arranged to enter the or a debug handler when an exception is raised due to a change-ofmode event (i. e. when an exception is generated), and subsequently to enter an exception handler. For example, the debug handler may be arranged to set up stored processor context such that, when a return-fromexception instruction is executed, the processor enters the exception handler, with the debug flag set. This may allow the exception handler to be debugged.

The processor may comprises a single step flag for enabling single step debugging. This may provide a convenient way of enabling and disabling single step debugging. The single step flag may be provided as part of the same register as the debug flag.

Preferably the single step flag is reset each time an exception is raised.

The processor described above may be arranged to debug an exception handler.

According to a third aspect of the present invention there is provided a method of debugging a processor, comprising: storing a debug flag; raising an exception when a debug related event occurs and the debug flag is set; and clearing the debug flag if an exception is raised as a consequence of a debug event.

According to a fourth aspect of the present invention there is provided a processor comprising: a register which stores a debug flag; a debug module which raises an exception when a debug related event occurs and the debug flag is set, and which clears the debug flag if an exception is raised as a consequence of a debug event.

At least some of the features described above may be implemented in software, and thus the invention also provides computer programs and computer program products for carrying out any of the methods described herein, and computer readable media having stored thereon programs for carrying out any of the methods described herein.

Features of one aspect may be applied to any other aspect; method features may be applied to apparatus aspects and vice versa- Preferred features of the present invention will now be described, purely by way of example, with reference to the accompanying drawings, in which :- Figure 1 is a schematic view of a debugging system; Figure 2 shows a process control register in accordance with an embodiment of-the present invention; Figure 3 shows a three-level stack for a program counter register; Figure 4 shows a three-level stack for a process control register; Figure 5 illustrates how a process control register is modified when an exception is raised in an embodiment of the present invention; Figure 6 shows a first example of debugging in an embodiment of the present invention; and Figure 7 shows a second example of debugging in an embodiment of the present invention.

Overview of a debugging system Fig. 1 is a schematic view of a debugging system suitable for debugging a processor core (CPU core) 2 in a system on chip (SOC) device 1. The aim of the debugging process is to identify and correct any problems associated with programs executed by the processor core 2. The debugging system comprises a debug module 3 forming part of the SOC device 1, a debug adaptor 4 and a host computer 5 running debugger software 6. The debug module 3 and debug adaptor 4 are able to communicate with one another via a debug link 7. The debug adaptor 4 can provide debug control

signals to the debug module 3 via the debug link 7 and can receive debug information generated by the debug module 3 via the debug link 7. The debug adaptor 4 and host computer 5 are able to communicate with one another via a data link 8, which is also a bidirectional link such as an Ethernet connection or a PCI bus.

The debug adaptor 4 comprises a combination of hardware and software capable of interfacing between the host computer 5 and the debug module 3, for example translating between different communication protocols used by the links 7 and 8, and buffering debug information received from the debug module 3 prior to onward transmission to the host computer 5.

Although Fig. 1 shows only a single processor core 1 being debugged, the Fig. 1 system may be used to debug an SOC (processor system) including a plurality of processor cores (processing units). In this case, the debug module 3 preferably supports all the processor cores, enabling each of them to be linked to the debug adaptor 4 via the debug link 7. Similarly, if the processor core in Fig. 1 has more than one individual processing unit (e. g. a VLIW processor core), the debug module 3 may handle debug information for all the individual processing units.

Incidentally, instead of using a debug adaptor 4 linked to a host computer 5 running debugger software 6 as shown in Fig. 1, it is possible to arrange for the debugger software 6 to be executed by the or each processor core being debugged. Such an arrangement has the advantage of dispensing with the debug adaptor 4 and host computer 5 but suffers from the disadvantage of being very intrusive in the normal execution of the

processor core (s).

When the debug module 3 detects a debug related event, it causes an exception to be raised. Exceptions are events which disrupt the normal execution sequence.

When an exception is raised the processor enters an exception mode, and executes a sequence of code called the exception handler. This processes the exception and then performs a return-from-exception (rfe) instruction to return the processor to the state it was in immediately prior to the exception being raised. It is necessary for the handler to return the processor to the exact same state it was in prior to the exception, because exceptions are expected to be transparent to the process currently running on the processor.

The act of raising an exception modifies a well-defined subset of the processor state. Typically this is at least the program counter (PC) which must be set to point to the start of the exception handler. The processor may also contain a Process Control Register (PCR) containing mode bits which indicate the current operating mode. This register must also be modified when an exception is raised or an rfe instruction is executed, as the mode bits change. When an exception is raised, the PC and PCR are saved (for example, onto a stack in memory, or in a register designated for that purpose) so that when an rfe instruction is executed the processor can return to the state it was in prior to the exception being raised.

It is useful to consider the processor as having a distinct operating mode for exception handlers, the operating system kernel, and user processes. These are referred to as exception mode, kernel mode and user mode respectively. Additional modes may be implemented

where appropriate.

Embodiments of the present invention In embodiments of the present invention, a special debug mode bit is provided which enables or disables all debug related exceptions. This bit is referred to as the B bit, and is provided as part of the processor context which is automatically saved when an exception is generated. When the B bit is set then debug related events cause an exception to be raised and the debug handler to be entered. When the B bit is cleared, debugging is disabled and debug related events do not cause an exception to be raised.

Debug related events that may cause an exception to be raised include the following: Hardware breakpoint. One or more breakpoint registers may be provided in the processor, each of which stores an address or a range of addresses. Each register also has an enable bit which enables or disables the breakpoint associated with that register. If a breakpoint register has its enable bit set, and the address stored in that register is referenced (or an address in the range of addresses is referenced) either when fetching instructions or when reading or writing data, then an exception is generated.

The same mechanism may be used to allow the debug module 3 to detect when the processor core reads or writes to specific source-code variables and/or to specific memory mapped registers.

Software breakpoint. A breakpoint instruction may be inserted into a section of code, for example by temporarily replacing an existing instruction with the breakpoint instruction. Execution of the

breakpoint instruction causes an exception to be raised.

Single-stepping. If single stepping is enabled then an exception is raised after each instruction has been executed. In embodiments of the present invention, single-stepping is enabled by a specific bit in the processor control register.

Non-sequential execution events. The processor may be set up so that an exception is raised each time a certain execution event occurs. Such events may include conditional branches, unconditional branches, subroutine calls and returns, system calls and interrupts. Control registers within the debug logic include bits for enabling/disabling such debug events.

Change in operating mode. The processor may be set up so that the debug handler is automatically entered when a change in operating mode occurs, i. e. when an exception is raised or an rfe instruction is executed. A control register within the debug logic includes a bit for enabling/disabling such a debug event.

CPU events. The processor may be set up so that the debug handler is automatically entered when a CPU event such as retiring of an instruction, a cache hit, a cache miss, a translation lookaside buffer (TLB) hit, a TLB miss, or a pipeline stall etc. occurs. Control registers within the debug logic include bits for enabling/disabling such debug events. The processor core 2 may also include counters so that each time a particular event is detected a count value is incremented.

As shown in Figure 2, the B bit is provided as part of a process control register (PCR). The process control register also comprises mode bits M which indicate

which mode the processor is in (e. g. exception mode, user mode, kernel mode), and another bit, referred to as the E bit, which enables or disables single stepping exceptions. If the E bit in the PCR is set, then a debug exception is raised after each instruction has been executed. This allows successive single-step exceptions to make forward progress through a program.

This is in contrast to breakpoint exceptions, where the breakpoint prevents the current instruction from being completed.

The registers PC and PCR, along with other registers containing items of processor state that are modified automatically by the raising of an exception or the execution of an rfe instruction, have two extra copies of those registers connected in hardware to form a three deep stack. These extra copies are individually readable and writeable by exception mode programs. A non-exception mode program may not read or write to or from the two copies, although it may have access to the state register itself.

The three deep stack for the program counter PC is shown in Figure 3. When an exception occurs, EPC is copied to EEPC and PC is copied to EPC. Then it is safe to set PC to point to the start of the exception handler. Conversely, when an rfe instruction is executed, EPC is copied to PC and EEPC is copied EPC.

In this way it is possible to maintain the PC state for a user mode program and up to two exception handlers.

By having EEPC as well as EPC, two levels of exception nesting can be tolerated before any context is lost.

When processing the second exception, the context of the first exception is in EPC and the context of the user mode process is in EEPC. Then, PC will point to

the next instruction to execute from the debug exception handler when a debug-related exception is raised during the processing of an exception handler.

The three deep stack for the process control register PCR is shown in Figure 4. The two copies of PCR are referred to as ECR and EECR respectively. When an exception is raised, ECR is copied to EECR and PCR is copied to ECR. On return from an exception, ECR is copied to PCR and EECR is copied to ECR, thus restoring the original values of the bits in PCR.

The contents of PC and PCR are modified automatically each time an exception is raised. As shown in Figure 4, if the exception is due to a debug related event, then the PCR. B bit (i. e. the B bit in the PCR) is cleared. In this case, the debug handling routine is entered, rather than the normal exception handling routine. By clearing the B bit when a debug exception is raised, it can be ensured that no further debug exceptions are raised while the debug handler is executing. If the exception is not a debug related exception then the PCR. B bit is not cleared, and the normal exception handling routine is entered. The PCR. E bit (i. e. the E bit in the PCR register) is cleared on all exceptions.

The above mechanism is illustrated in Figure 5. At time T=0 the processor is executing in user mode, which here is indicated by the mode bit M being cleared, and the B bit is set. At time T=1 a debug exception is raised. This causes the contents of PCR to be copied to ECR. The mode bit in PCR is set to 1 to indicate exception mode, and the B bit is cleared. The processor then enters the debug handler. Since the B bit is cleared, further debug exceptions will not be

raised while the debug handler is being executed.

At time T=2 an rfe instruction is executed, to return control back to the user process that is being debugged. When the rfe instruction is executed, the contents of ECR are copied back to PCR. Since the B bit is again set, debugging may continue as before.

It is possible that an interrupt is pending when the user process is re-started after the debug exception.

In this case an interrupt will be taken in preference to any subsequent debug exception. Within the interrupt handler the operating system process scheduler may be called, and a completely different process may be scheduled. This will save the current PCR value (with the B bit set) within the context save area for the current process, and load PCR with the correct PCR value for the process being scheduled. If the process being scheduled is not being debugged, then the new PCR will have the B bit cleared. When the process being debugged is re-scheduled, the PCR value with the B bit set will be re-loaded and debugging will continue.

The mechanism described above means that it is not necessary for the scheduler to disable specific debug events. This can avoid the need to provide a complex mechanism for enabling/disabling all debug related events individually. If the B bit were not provided and, for example, a hardware breakpoint needed to be disabled, then the scheduler would need to write to the bit in the breakpoint register which enabled/disabled that breakpoint. If a software breakpoint were to be disabled, the scheduler would need to replace the breakpoint instruction in the code being debugged with another instruction, such as the instruction which the

breakpoint instruction replaced. In addition, the scheduler would need to keep track of which debug events were disabled, so that it could re-enable them when the process being debugged was re-scheduled.

By providing the B bit which disables all debug related events, a simple mechanism is provided for debugging a single process (or any subset of the total number of processes) in a multi-thread environment. The scheduler need not even be aware that a particular process is being debugged.

If an address range selected by a breakpoint contains a subroutine that is commonly referenced by other processes, such as a function implementing an operating system service, then the existence of the B bit allows the debug mechanism to be thread safe. Thus, only processes which are being debugged will raise debug exceptions, even though the operating system may be time-slicing other processes which may execute instructions within a breakpoint range.

Since the B bit is used to enable/disable debugging when a thread which is being debugged is time sliced with another thread, the timing of events in the thread that is being debugged is the same as would be the case if the thread were not being debugged, up until the point where a debug exception is taken. By contrast, if it were necessary for the scheduler to enable specific debug events each time the thread was entered, and to disable those debug events each time the thread was exited, this would cause the timing of events in the thread to be different depending on whether or not the thread was being debugged. This may cause bugs which occur when a thread is not being debugged to act differently, or not to occur at all, while the thread

is being debugged (so-called"Heisenbugs"). The present embodiment may avoid this situation, by ensuring that the timing of events in a thread that is being debugged is the same as if the thread were not being debugged, even if the thread is being time sliced with another thread.

Some examples of how the mechanism described above may be used to debug embedded code will now be described.

Single stepping though a sequence of instructions In this example it is assumed that a user wishes to single step through a sequence of instructions which occur after the address 0x100 (100 hex). In order to achieve this, a breakpoint is first set at address 0x100, for example by writing the address 0x100 to a breakpoint register and setting the enable bit for that register. The B bit is then set (PCR. B = 1). This will cause a breakpoint exception to be generated when the program counter advances to 0x100.

The sequence of events is illustrated in Figure 6.

Referring to Figure 6, at T=0 the program counter advances to address 100. At that time, the mode bit M in the PCR is cleared (PCR. M = 0) indicating that the processor is in user mode, the B bit is set and the E bit is cleared. Since a breakpoint has been set at address 100 and the B bit is set, a debug exception is then raised.

The events which take place when the debug exception is raised are shown at T=1. The contents of PC are copied to EPC and the contents of PCR are copied to ECR. The address of the debug handler is written to PC, which in Figure 6 is indicated by"D"in PC. In the PCR, the M bit is set, indicating exception mode, and the B bit is

cleared. Since PC contains the address of the debug handler, the debug handler is then executed.

In order to enable single stepping through the subsequent instructions in the user program, at T=2 the debug handler sets the ECR. E bit to 1 and the ECR. B bit to 1. At this time the debug handler also clears the breakpoint at address 100. This is done by clearing the enable bit in the breakpoint register, if the breakpoint is a hardware breakpoint, or by removing the breakpoint instruction if it is a software breakpoint (e. g. by re-inserting the original instruction that was replaced by the breakpoint instruction).

At T=3 an rfe instruction is executed, which returns control to the process which originally caused the breakpoint. Since the breakpoint is now disabled, the instruction at address 100 is executed, and PC is advanced to 0x101 (T=4 in Figure 6).

At T=5, a debug exception is again raised, since single stepping is now enabled, and the instruction at address 100 has just been executed. The contents of PC are copied to EPC and the contents of PCR are copied to ECR. The M bit in PCR is set to 1, and the B bit and the E bit are both cleared. PC is set to the address of the debug handler. This causes the debug handler to be entered. The debug handler can then take whatever action is required in response to the exception (such as displaying the contents of the processor's registers to the user). If it is required to continue with single stepping, then the debug handler keeps ECR. B = 1 and ECR. E = 1 and executes an rfe instruction. In this way the debugger can continue to single step through subsequent instructions.

Debugging an exception handler To debug an exception handler, the debugger configures the debug hardware so that it enters the debug handler whenever the processor attempts to change mode (i. e. when it attempts to raise an exception). This is done by setting a bit in one of the debug registers which enables such a debug event. The debug handler thus effectively replaces the handler of the exception which lead to the change of mode; however, the values which are copied into EPC and ECR are not affected by this.

The debug handler may then execute any instructions it needs to save the contents of registers and to determine which actual handler should be executed for the original exception.

An example of how an exception handler may be debugged will now be described with reference to Figure 7.

Referring to Figure 7, at T=0 a user mode program at address A is being executed, and it is assumed that this program causes an exception to be raised. The B bit in PCR is set, and it is assumed that change-ofmode debug events are enabled (i. e. the appropriate bit in one of the debug registers is set). This set of conditions will cause a debug exception to be raised, in place of a normal exception. Thus, at T=1, PC is copied to EPC, PCR is copied to ECR, the address D of the debug handler is written to PC, the M bit in PCR is set (indicating exception mode) and the B bit is cleared. Since PC contains the address of the debug handler, the debug handler is then entered.

At T=2, the debug handler copies ECR to EECR and copies PCR to ECR, and also copies EPC to EEPC. The debug handler can then set up the processor for debugging of the handler of the original exception. In this example, it is assumed that it is required to single

step through the exception handler. In order to achieve this, at T=3, the debug handler sets the ECR. E bit and the ECR. B bit, and writes the address of the entry point of the handler of the original exception (address X) into EPC. The debug handler also sets the ECR. M bit to indicate exception mode. At this point, the context of the user mode program is held in EEPC and EECR, while EPC and ECR have been set up to hold the context of the exception handler, with debugging enabled.

At time T=4 an rfe instruction is executed. The effect of this is to enter the handler of the original exception, with single stepping enabled (i. e. with the B bit and the E bit both set). At this point the context of the user mode program is held in EPC and ECR.

Between T=4 and T=5 the first instruction of the exception handler (which is being debugged) is executed, and PC is incremented to the address of the next instruction (note that all addresses in the exception handler are shown generally as"X"). At T=5, a single step exception is raised because PCR. E is set.

ECR is copied to EECR, PCR is copied to ECR, and the B and E bits in PCR are cleared. At the same time, EPC is copied to EEPC, PC is copied to EPC, and PC is set to the address of the debug handler. This causes the debug handler to be entered. At this point the context of the user mode program is again held in EEPC and EECR, and the context of the original handler is held in EPC and ECR. PC points at the instruction in the debug handler and PCR has the E bit clear to prevent single stepping of the debug handler. The debug handler can then take the appropriate action in response to the single step exception, such as

displaying the contents of the processor's registers to the user.

At T=6 an rfe instruction is executed. This returns control to the next instruction of the exception handler with PCR. E and PCR. B again set. In this way the debugger can continue to single step through subsequent instructions in the exception handler.

It is also possible to trigger a breakpoint (or other debug event) whilst executing an exception handler. If a debug event has been triggered-by a mode change (i. e. an exception occurred, change-of-mode debug events are enabled, and PCR. B is set), then the debug handler will report the change of mode to the user via the debug interface. At that point a user may wish to set a breakpoint on a range of addresses within the exception handler itself, so as to be selective about which parts of the handler to debug. This requires that the ECR. B bit is set and the ECR. E bit is clear prior to returning from the debug handler to the original exception handler. If no such breakpoints are generated, and the handler itself returns to the user mode program, then the breakpoint enable will be disabled when the rfe instruction is executed, because the PCR of the user mode program will be restored from ECR. This prevents subsequent spurious breakpoints.

In the present embodiment, two levels of exception nesting can be tolerated before any context is lost.

The processor looks at the mode bits in ECR and EECR to determine whether the stack of exception states is about to overflow. For example, if ECR. M (the mode bit in ECR) indicates exception mode, then it is known that another exception will overwrite the user mode contents of EECR and EEPC. To deal with this, the processor

vectors such exceptions into a special"exception stack overflow"handler. If an exception occurs when EECR. M indicates exception mode, then it is known that an exception has occurred in the handler for exception stack overflows. This is considered a fatal error and will halt the processor. It indicates a serious fault somewhere in the system, as the handler should have been coded to completely avoid exceptions. Note that interrupts will be disabled in that handler by default.

The present embodiments may provide following advantages.

The logic associated with PCR. B and PCR. E enables a simple implementation of single stepping and breakpoints in a thread safe manner. Each thread, and each invocation of an exception handler, have individual control over the enabling or disabling of single step and breakpoint exceptions.

Exception handlers do not need to know anything about the debug specific registers which define breakpoint ranges and breakpoint conditions. High level control of breakpoints is handled by the PCR. B bit. This means that handlers for different versions of a processor, with different numbers of breakpoint region registers, can be identical.

Single stepping through a region of code within a breakpoint range is fast and efficient. It requires only that PCR. E and PCR. B are properly manipulated by the breakpoint handler and the single step handler.

Controlling breakpoint exceptions with the PCR. B bit decouples the breakpoint logic from the internal logic of the processor, and makes it possible to implement hardware to detect breakpoint ranges and to trigger breakpoint

exceptions which are then enabled or disabled by a single architecturally-visible mode bit.

By accessing saved copies of the context registers, the debug handler can set up the processor context prior to entering an exception handler, which can facilitate debugging of the exception handler. For example, the effects of an exception can be imitated by placing suitable user mode values in EECR and EEPC and then performing an rfe instruction to jump to the exception handler. At that point the ECR and EPC values appear to the handler as the context of a user mode program at the time the exception occurred.

The handler has no way of knowing that it was reached via an rfe instruction rather than an exception.

Since the B bit is reset when a debug related exception is raised, but not otherwise, it is possible to"lock out"further debug related exceptions (i. e. prevent such exceptions from being raised). However, other non-debug exceptions are not disabled. If all exceptions were disabled it would be possible for the processor to enter into a non-recoverable state due to an event which would otherwise have raised an exception.

It will be understood that the present invention has been described above purely by way of example, and modifications of detail can be made within the scope of the invention.

Each feature disclosed in the description, and (where appropriate) the claims and drawings may be provided independently or in any appropriate combination.

Claims

1. A processor comprising: a debug handler for handling a plurality of debug related events occurring within the processor; and a debug flag for enabling and disabling the plurality of debug related events.

2. A processor according to claim 1 wherein the debug flag is cleared if an exception is raised as a consequence of a debug event.

3. A processor comprising: means for storing a debug flag; means for raising an exception when a debug related event occurs and the debug flag is set; and means for clearing the debug flag if an exception is raised as a consequence of a debug event.

4. A processor according to claim 2 or 3 wherein the debug flag is not cleared if an exception is raised by an event other than a debug event.

5. A processor according to any of the preceding claims wherein the debug flag is copied to a storage location when an exception is raised.

6. A processor according to any of the preceding claims wherein the debug flag is part of a control register.

7. A processor according to claim 6, wherein the contents of the control register are copied to a storage location when an exception is raised.

8. A processor according to any of the preceding

claims, the processor comprising a multi-level stack for storing processor context when an exception is raised.

9. A processor according to claim 8 wherein the processor is arranged such that the or a debug handler is able to read to and/or to write from at least two levels of the multi-level stack.

10. A processor according to any of the preceding claims wherein the processor is arranged to enter the or a debug handler when an exception is raised due to a debug related event.

11. A processor according to any of the preceding claims, wherein the debug related events comprise at least one of a breakpoint event, a single step event, a change in operating mode event, a non-sequential execution event, or a CPU event.

12. A processor according to any of the preceding claims wherein the processor is arranged to enter the or a debug handler when an exception is raised due to a change-of-mode event, and subsequently to enter an exception handler.

13. A processor according to claim 12 wherein the debug handler is arranged to set up stored processor context such that, when a return-from-exception instruction is executed, the processor enters the exception handler with the debug flag set.

14. A processor according to any of the preceding claims, further comprising a single step flag for enabling single step debugging.

15. A processor according to claim 14, wherein the single step flag is reset each time an exception is raised.

16. A processor according to any of the preceding claims, arranged to debug an exception handler.

17. A method of debugging a processor, comprising: storing a debug flag; raising an exception when a debug related event occurs and the debug flag is set and clearing the debug flag if an exception is raised as a consequence of a debug event.

18. A method substantially as described herein with reference to the accompanying drawings.

19. Apparatus substantially as described with reference to and as illustrated in the accompanying drawings.