Technology for collecting device status information

Abstract

Technology for collecting device status information A technique for collecting state information of a device is provided. The device includes a processing pipeline for executing a sequence of instructions and an instruction-of-interest designation circuit for identifying at least one instruction in the sequence as an instruction of interest. Each instruction of interest is an instruction for which given state information of the device associated with execution of the instruction of interest should be collected. The instruction-of-interest designation circuit is configured to apply defined selection criteria to each identified instruction of interest to determine a further instruction that follows the instruction of interest in the sequence of instructions and mark the further instruction as having a synchronization exception associated therewith. In response to the further instruction reaching a given stage of the processing pipeline and being marked as having a synchronization exception associated therewith, the processing pipeline triggers a synchronization exception instead of executing the further instruction, thereby causing the processing pipeline to execute a given exception handling routine to collect the given state information.

Description

[Technical Field]

[0001] The present technology relates to mechanisms for collecting device status information.

[0002] There are many situations in which it is desirable to monitor program execution. When performing such monitoring of program execution, it is often desirable to take an exception to the monitoring code at some point so that information about the program's execution can be extracted. For example, when performing statistical profiling, the execution of particular instructions may cause a record to be created to capture information related to the execution of those instructions, and an exception may then be raised. Typically, this is an asynchronous exception, sometimes referred to as an interrupt, that is issued to an interrupt controller that prioritizes among multiple interrupt sources. With such an approach, the interrupt controller can trigger the appropriate exception handling routine to reference the record created by such statistical profiling.

[0003] As another example, performance monitoring techniques may be used to track the occurrence of particular events, for example using a series of counters, and at particular points in time, asynchronous exceptions may be generated to an interrupt controller to execute an exception handling routine to review event information maintained as a result of such performance monitoring.

[0004] In addition to the above information that may be captured when monitoring program execution, it may be desirable to capture other information about the state of the device at the time the event that caused the information to be captured by these program monitoring techniques occurred. However, because program execution continues between the time an asynchronous exception is selected by the interrupt controller and the execution of the exception handling routine, the state of the system when the exception handling routine is executed may not accurately reflect the state of the system at an earlier point in time of interest, and therefore it may be difficult to correlate such device state information with information obtained from monitoring program execution. Summary of the Invention

[0005] In one exemplary configuration, an apparatus is provided comprising: a processing pipeline that executes a sequence of instructions; and an instruction-of-interest designation circuit for identifying at least one of the instructions in the sequence as an instruction of interest, each instruction of interest being an instruction for which given state information of the apparatus associated with execution of the instruction of interest is to be collected; the instruction-of-interest designation circuit is configured to apply, to each identified instruction of interest, defined criteria to determine a further instruction that follows the instruction of interest in the sequence of instructions and mark the further instruction as having a synchronization exception associated with it; and the processing pipeline, in response to the further instruction reaching a given stage in the processing pipeline and being marked as having a synchronization exception associated with it, triggers the synchronization exception instead of executing the further instruction, thereby causing the processing pipeline to execute a given exception handling routine to collect the given state information.

[0006] In another exemplary configuration, there is provided a method of collecting given state information of a device, the method including: using a processing pipeline to execute a sequence of instructions; identifying at least one of the instructions in the sequence as an instruction of interest, each instruction of interest being an instruction for which given state information of the device associated with execution of the instruction of interest is to be collected; for each identified instruction of interest, applying defined criteria to determine a further instruction that follows the instruction of interest in the sequence of instructions and marking the further instruction as having a synchronization exception associated therewith; and in response to the further instruction reaching a given stage of the processing pipeline and being marked as having a synchronization exception associated therewith, triggering the synchronization exception instead of executing the further instruction, thereby causing the processing pipeline to execute a given exception handling routine to collect the given state information.

[0007] In yet another exemplary configuration, there is provided a computer program for controlling a host data processing apparatus to provide an instruction execution environment, the computer program including: processing program logic for executing a sequence of instructions in a series of pipeline stages; and interest instruction designation program logic for identifying at least one of the instructions in the sequence as an instruction of interest, each instruction of interest being an instruction for which given state information associated with execution of the interest instruction should be collected; the interest instruction designation program logic is configured to, for each identified instruction of interest, apply defined criteria to determine a further instruction that follows the instruction of interest in the sequence of instructions and mark the further instruction as having a synchronization exception associated therewith; and the processing program logic, in response to the further instruction reaching a given pipeline stage and being marked as having a synchronization exception associated therewith, triggers the synchronization exception instead of executing the further instruction, thereby causing the processing program logic to execute a given exception handling routine to collect the given state information.

[0008] In yet another exemplary configuration, an apparatus is provided comprising: processing pipeline means for executing a sequence of instructions; instruction-of-interest designation means for identifying at least one of the instructions in the sequence as an instruction of interest, each instruction of interest being an instruction for which given state information of the apparatus associated with execution of the instruction of interest should be collected, the instruction-of-interest designation means being configured to, for each identified instruction of interest, apply defined criteria to determine a further instruction that follows the instruction of interest in the sequence of instructions and mark the further instruction as having a synchronization exception associated with it; and processing pipeline means for, in response to the further instruction reaching a given stage of the processing pipeline means and being marked as having a synchronization exception associated with it, triggering the synchronization exception instead of executing the further instruction, whereby the processing pipeline means executes a given exception handling routine to collect the given state information. [Brief explanation of the drawings]

[0009] The present technique will now be further described, by way of example only, with reference to examples of the technique illustrated in the accompanying drawings, in which: [Figure 1] FIG. 1 is a block diagram of an apparatus according to an exemplary implementation. [Figure 2] 2 is a flow diagram illustrating the operation of the interest instruction designation circuit of FIG. 1 in one exemplary configuration. [Figure 3] FIG. 10 is a flow diagram illustrating operation of a processing pipeline in response to further instructions identified by an instruction of interest designation circuitry, according to one exemplary configuration. [Figure 4] FIG. 1 is a flow diagram that schematically illustrates the use of a call stack buffer during program execution. [Figure 5A] 1 illustrates various types of criteria that may be used to determine further instructions according to the techniques described herein. [Figure 5B] 1 illustrates various types of criteria that may be used to determine further instructions according to the techniques described herein. [Figure 5C] 1 illustrates various types of criteria that may be used to determine further instructions according to the techniques described herein. [Figure 6] FIG. 1 is a flow diagram illustrating a statistical profiling technique that may be used in an example implementation. [Figure 7] FIG. 10 is a flow diagram illustrating an alternative statistical profiling technique that may be used, according to an example implementation in which a filtering mechanism is used. [Figure 8] FIG. 1 is a flow diagram illustrating a performance monitoring technique that may be used, according to an example implementation. [Figure 9] FIG. 10 is a flow diagram illustrating how an instruction of interest designation circuit may be used in connection with a call stack buffer, according to an exemplary implementation. [Figure 10] 1 illustrates a simulator implementation that may be used.

[0010] As mentioned above, there are various techniques that can be used to monitor program execution, including statistical profiling, which generates records related to the execution of specific instructions, and performance monitoring, which allows you to track the occurrence of specific events as the program runs. In the case of performance monitoring, these events are often caused by the execution of specific instructions.

[0011] In accordance with the techniques described herein, an apparatus is provided having a processing pipeline for executing a sequence of instructions, and an instruction-of-interest designation circuit for identifying at least one of the instructions in the sequence as an instruction of interest, each instruction of interest being an instruction for which given state information of the apparatus associated with execution of the instruction of interest is to be collected.

[0012] Therefore, according to the techniques described herein, certain instructions are identified as instructions for which it is desirable to obtain associated state information about the state of the device when those instructions were executed. However, as mentioned above, when monitoring program execution, asynchronous exception mechanisms are typically used. In particular, circuits provided within the device for monitoring program execution may generate asynchronous exceptions at certain times, which are then handled by an interrupt controller, resulting in the invocation of an exception handling routine to handle these asynchronous exceptions. However, when such mechanisms are used following the execution of an instruction of interest, it has been found that there is a significant gap between the time the instruction of interest is executed and the subsequent time the exception handling routine is executed. Therefore, although such an exception handling routine may be configured to collect the necessary state information of the device, the collected state information may not accurately represent the state of the device when the instruction of interest was executed and may therefore be of little use.

[0013] Another type of exception that exists is a synchronous exception. When a synchronous exception is associated with an instruction, the instruction is not executed, but rather the synchronous exception is taken when the instruction is encountered, for example, when the instruction reaches a particular stage in the processor pipeline. The use of synchronous exceptions can be useful in various situations, for example, to implement an "instruction fault" mechanism. For example, if a load or store instruction attempts to access an area of memory that the user does not have permission to access, the synchronous exception technique can be used to generate a fault instead of attempting to execute the load or store instruction.

[0014] However, raising a synchronous exception instead of executing the instruction of interest is not useful because the instruction of interest needs to be executed so that certain state information of the device associated with the execution of that instruction of interest can be captured, and the instruction of interest may need to be executed so that information related to the execution of that instruction can be obtained by the program monitoring circuitry described above, such as the statistical profiling or performance monitoring circuitry mentioned above.

[0015] According to the techniques described herein, the above-mentioned concept of synchronous exceptions is utilized to mitigate the aforementioned problems associated with the skid between the time an asynchronous exception occurs and the time an associated exception handling routine is invoked, but not with the instruction of interest itself. In particular, the instruction of interest designation circuit is configured to apply defined criteria to each identified instruction of interest to determine a further instruction that follows the instruction of interest in the sequence of instructions, and then mark the further instruction as having a synchronous exception associated with it. Depending on the criteria used to select the instruction of interest, the further instruction may have already been fetched by the processing pipeline; if not, the instruction of interest designation circuit enters a state in which it monitors fetched instructions and waits for an instruction that meets the criteria (e.g., the next instruction of a particular type) to be fetched, at which point it can identify the instruction as the further instruction.

[0016] The processing pipeline then triggers a synchronous exception instead of executing the further instruction in response to the further instruction reaching a given stage in the processing pipeline and being marked as having a synchronous exception associated with it. This causes the processing pipeline to execute a given exception handling routine to collect given state information. The given stage in the processing pipeline that causes the synchronous exception to be triggered when the further instruction reaches that stage may be any suitable stage within the processing pipeline. For example, it may be the execution stage where the further instruction is executed, in which case the synchronous exception is triggered instead of executing the further instruction. However, the given stage may alternatively be an earlier stage than the execution stage, in which case the synchronous exception is again triggered instead of allowing the further instruction to proceed to execution.

[0017] It should be noted that in addition to the execution of a given exception handling routine used to collect given state information, the device can also collect additional information using other existing mechanisms, such as the statistical profiling or performance monitoring mechanisms described above. Due to the given state information collected by a given exception handling routine triggered by a synchronous exception when a further instruction reaches a given stage of the processing pipeline, it is much more likely that the given state information can be correlated with other information, including, for example, information associated with the execution of the instruction of interest. In particular, because the further instruction is selected by the interest instruction designation circuit depending on the identified instruction of interest, there is a much more deterministic correlation between the execution time of the instruction of interest and the time at which the given exception handling routine is executed in response to a synchronous exception triggered by the further instruction than when the asynchronous exception mechanism described above is used.

[0018] However, it should be noted that the above techniques are useful even in the absence of other information being collected by other components in the system. In particular, the given state information may, in fact, be the only information collected, but may still usefully provide information correlating with the execution of the instruction of interest due to the manner in which the further instructions are selected by the instruction-of-interest designation circuitry.

[0019] As described above, because a synchronous exception is associated with a further instruction, the processing pipeline triggers a synchronous exception when the further instruction reaches a given stage in the processing pipeline instead of allowing the further instruction to execute. In one exemplary implementation, the processing pipeline may be configured to execute the further instruction when execution eventually returns from a given exception handling routine. Thus, the association of a synchronous exception with the further instruction may simply effectively delay execution of the further instruction while the exception handling routine is executed.

[0020] The defined criteria applied by the instruction-of-interest designation circuit to determine further instructions for each identified instruction of interest can take various forms. In one exemplary implementation, the defined criteria cause the instruction-of-interest designation circuit to determine, as the further instruction, an instruction that appears in a predetermined position in the sequence of instructions relative to the instruction of interest. Thus, the instruction-of-interest designation circuit can simply select the Nth instruction following the instruction of interest as the further instruction, where N can be selected depending on the implementation. For example, how N is selected can depend on expected instruction dependencies. For example, if instruction X of interest is immediately followed by instruction Y in the instruction sequence, but the processing pipeline enables out-of-order execution and instruction Y typically actually executes before instruction X, associating a synchronization exception with instruction Y enforces ordering between instruction X and instruction Y and prevents instruction Y from executing until after instruction X. This could potentially cause some probe effect that may be desired to be avoided, in which case it may be determined to set N greater than 1. However, if there are no such instruction dependency issues, it may be determined appropriate to set N equal to 1 to minimize the gap between the instruction of interest being executed and the synchronization exception being triggered from the further instruction.

[0021] As another example, the defined criteria may cause the instruction-of-interest designation circuit to determine as the further instruction at least one instruction of a given type that appears in the sequence of instructions following the instruction of interest. Various types of instructions may be selected here, but of particular interest are instructions that, when executed, may cause a change to given state information that is desired to be collected. In particular, as explained above, it is desirable for the given state information to provide useful information about the state of the device when the instruction of interest was executed, and therefore it is desirable to avoid execution of subsequent instructions that may change the given state information so as to prevent the type of state information at the time the instruction of interest was executed from being determined.

[0022] As an example of a particular type of instruction that may be desired to be considered by the interest instruction designation circuitry when selecting further instructions, a particular type of load or store instruction may be of interest because it will change the contents of a register bank. As another example, an executing program may be composed of several different subroutines. Some types of instructions cause transitions between those subroutines, which in turn cause changes to the contents of certain state information maintained by the device to track those subroutines. As an example, a call stack buffer may maintain information used to handle transitions between subroutines, with each transition to a new subroutine adding an entry to the top of that buffer to capture information that will eventually be used when returning from that subroutine. Similarly, each return from a subroutine causes the most recently added entry to the call stack buffer to be removed, consuming the information stored there.

[0023] The defined criteria applied by the instruction-of-interest designation circuitry may monitor any number of instructions of a given type, and may be configured, for example, to consider all of the above examples of instructions, or only a subset thereof, and determine as a further instruction the next instruction of one or more monitored types that appears in the sequence of instructions after the instruction of interest. Alternatively, the defined criteria may be such that the instruction-of-interest designation circuitry does not designate as a further instruction the next instruction of one or more monitored types that appears in the sequence of instructions, but instead designates the Nth instruction of one or more monitored types that appears in the sequence of instructions.

[0024] In one exemplary embodiment, at least one instruction of the given type may be a return instruction used to return the processing pipeline to execution of program code that was executing prior to execution of a current subroutine. Alternatively, or additionally, at least one instruction of the given type may be a branch-and-link instruction that, when executed, causes the processing pipeline to stop processing a current subroutine and begin executing a further subroutine.

[0025] The current subroutine referred to above when describing the return and branch with link instructions can take a variety of forms, but in one exemplary implementation, the current subroutine can be the subroutine that contains the instruction of interest, and therefore, using the techniques described above, a synchronization exception can be associated with a further instruction that appears within the same subroutine as the subroutine that contains the instruction of interest, thereby allowing given state information (such as the contents of the call stack buffer mentioned above) to be captured by the exception handling routine before the subroutine change is made and therefore before the given state information of interest may be changed in a way that prevents the determination of the form of that state information when the instruction of interest is executed.

[0026] As another exemplary approach that can be taken to determine the further instruction, the defined criteria may be such that the interest instruction designation circuit determines as a further instruction any instruction that appears in the sequence of instructions after the instruction of interest up to, but not more than, the next instruction of at least one given type that appears in the sequence of instructions after the instruction of interest. Thus, when employing such an approach, the actual instruction selected as the further instruction is not considered critical if it is an instruction up to, but not more than, the next instruction of a particular type that appears after the instruction of interest. Purely by way of example, it may be desirable for a synchronization exception to occur before the next linked branch instruction after encountering the instruction of interest, or at least no later than the time the next linked branch instruction is encountered; the approach described above can achieve this goal without strictly restricting which instructions have a synchronization exception associated with them.

[0027] In one exemplary implementation, the apparatus further includes a statistical profiling circuit that, in response to execution of a given instruction of interest, generates a record including multiple items of information regarding the execution of the given instruction of interest. In such an implementation, given state information collected by executing a given exception handling routine may include additional information not included in the record generated by the statistical profiling circuit. Thus, by using the above-described mechanism, information regarding the information collected in the record generated by the statistical profiling circuit can be obtained through the execution of a given exception handling routine.

[0028] The multiple items of information generated by the statistical profiling circuitry in the record can take a variety of forms, but as a purely non-exhaustive example, the record may identify the instruction address of the instruction of interest, the instruction type (e.g., whether it is a branch instruction, a load instruction, a store instruction, etc.), the execution context (e.g., what exception level the processing pipeline is at and therefore, for example, whether the processing pipeline operates in user space, operating system space, or hypervisor space), which software process is executing at that exception level (sometimes referred to as a context identifier), the latency of the instruction of interest, etc.

[0029] The additional information that forms the given state information collected by executing a given exception handling routine can take a variety of forms, but in one example, it includes at least one item of software-defined state associated with the execution of a given instruction of interest. Such software-defined state is not naturally captured by statistical profiling circuitry, but can provide useful additional information when attempting to analyze the record generated for the instruction of interest. For example, it can be used to determine which paths of instruction execution were followed before reaching the instruction of interest.

[0030] Although software-defined state can take a variety of different forms, one item of such software-defined state may include the contents of the aforementioned call stack buffer maintained by the device. By having knowledge of the contents of the call stack buffer, it may be possible to determine the sequence of subroutines that were executed before the subroutine containing the instruction of interest.

[0031] In one exemplary implementation, the statistical profiling circuitry is further configured to include, within the plurality of information items regarding the execution of a given instruction of interest, an indication of the current call stack buffer pointer value at the time the given instruction of interest was executed. In situations where the given state information collected by the execution of a given exception handling routine includes at least the contents of the call stack buffer, providing this additional information in the record, i.e., the call stack buffer pointer value that existed when the given instruction of interest was executed, can assist in interpreting the contents of the call stack buffer. In particular, even if the call stack buffer pointer changes between the time the instruction of interest was executed and the time the contents of the call stack buffer were collected by the exception handling routine, it may be possible to accurately reconstruct the contents of the call stack buffer at the time the instruction of interest was executed, provided with the additional information regarding the call stack buffer pointer value that existed at the time the instruction of interest was executed.

[0032] This information about the current call stack buffer pointer value that existed when a given instruction of interest was executed can be used directly by the exception handling routine to determine what portion of the call stack contents to collect, or the exception handling routine can capture the entire call stack contents, and then use information about the current call stack buffer pointer value when a given instruction of interest was executed when analyzing the captured call stack contents.

[0033] There are several ways in which the instruction of interest designation circuitry may be configured to identify each instruction of interest. However, in one exemplary implementation, the instruction of interest designation circuitry is configured to apply selection criteria to identify each instruction of interest for which the statistical profiling circuitry should record multiple items of information when the instruction of interest is executed. There are several forms of selection criteria that can be used. For example, the selection criteria may be configured to select every Nth instruction, or may apply more complex criteria, such as attempting to detect the occurrence of a particular type of instruction that is then selected as an instruction of interest.

[0034] When using the techniques described herein, in a situation where statistical profiling is performed, the statistical profiling circuitry can be configured to generate a record for each identified instruction of interest, and further identify additional instructions for each instruction of interest, each of which has an associated synchronous exception to cause a given exception handling routine to be executed when the additional instruction reaches a given stage in the processing pipeline, using the synchronous exception mechanism described above. This allows the aforementioned given state information to be collected by the exception handling routine, for example, to be used in combination with the record generated by the statistical profiling circuitry for each instruction of interest, but may increase the number of exceptions executed. For example, without using this technique, the statistical profiling circuitry may generate records for multiple instructions of interest, store the records in a buffer, and then issue an asynchronous exception at a given time, resulting in an exception not necessarily being taken for all instructions of interest.

[0035] While the currently described technique has the advantage of allowing device-specific state information to be collected for each instruction of interest, in some cases it may be desirable to reduce the amount of exception handling required within the device. In one exemplary implementation, this is achieved by configuring the selection criteria to include initial selection criteria and further selection criteria. The instruction-of-interest designation circuit may then be configured to apply the initial selection criteria to identify candidate instructions of interest. However, the instruction-of-interest designation circuit may further include a filter circuit that applies the further selection criteria to determine which candidate instructions of interest should be used as actual instructions of interest. Thus, it is possible to filter out some of the initially selected candidate instructions of interest, thereby reducing the number of times an exception handling routine is triggered in response to a synchronization exception associated with the corresponding further instructions.

[0036] The time at which the filtering mechanism is performed may vary depending on the implementation. For example, in one implementation, the filter circuit may be configured to treat a candidate instruction of interest as an instruction of interest only if the type of the candidate instruction of interest is one or more given types of instructions. Thus, with such an approach, filtering may be applied relatively early in the pipeline, for example, at the decode stage, to reduce the number of instructions of interest that will be considered by the device.

[0037] Alternatively or additionally, however, the filter circuitry may be configured to treat a candidate instruction of interest as an instruction of interest if a given behavior is observed when the candidate instruction of interest is executed. Thus, according to such an approach, a candidate instruction of interest may be passed through the pipeline, and a decision as to whether the candidate instruction of interest should actually be treated as an instruction of interest may be postponed until the execution behavior of the candidate instruction of interest is known. This may allow interesting instructions to be effectively excluded from further consideration as instructions of interest if their execution behavior is uninteresting. As a purely illustrative example, load or store instructions may be identified as candidate instructions of interest, but only those attempting to collect the aforementioned given state information in association with a load or store instruction having a relatively long latency may be determined to be interesting. Thus, any load or store instructions that execute relatively quickly may be excluded from further consideration as instructions of interest at that stage, such that only load or store instructions that execute relatively slowly are retained as instructions of interest, and therefore their associated further instructions have synchronization exceptions retained associated with them.

[0038] In one exemplary implementation, the statistical profiling circuitry obtains multiple information items regarding the execution of a given candidate instruction of interest in response to the execution of the given candidate instruction of interest, but maintains a record including the multiple information items only if the filter circuitry determines that a given behavior has been observed. Thus, the statistical profiling circuitry may initially treat the candidate instruction of interest like any other instruction of interest and begin to collect together multiple information items that it wishes to store in a record associated with the instruction of interest. However, if the aforementioned given behavior of the candidate instruction of interest is not observed when the instruction is executed, it may decide not to maintain a record of the instruction of interest.

[0039] With respect to processing of further instructions, if no records are maintained for the associated candidate instruction of interest, the device may be configured to not take a synchronization exception when the further instruction is encountered, but instead to simply allow the further instruction to proceed to execution as normal.

[0040] There are several ways in which the further instructions associated with the candidate instruction of interest can be processed. In one exemplary implementation, only when the candidate instruction of interest is treated as an actual instruction of interest by the filter circuitry is the associated further instruction marked as having a synchronization exception associated with it when the further instruction reaches a given stage of the processing pipeline. Thus, if the candidate instruction of interest is no longer treated as an actual instruction of interest by the time the further instruction reaches that stage of the processing pipeline, the further instruction may no longer be treated as having a synchronization exception associated with it.

[0041] In one example implementation, the further instruction may have a synchronization exception associated with it only after it is determined that the candidate instruction of interest was an actual instruction of interest. Alternatively, the further instruction associated with the candidate instruction of interest may initially have a synchronization exception associated with it, but if it is later determined that the candidate instruction of interest is not to be treated as an actual instruction of interest, that synchronization exception association may be removed from the further instruction.

[0042] In some example implementations, the apparatus may further include a performance monitoring circuit for maintaining a record indicating the occurrence of one or more events during execution of the sequence of instructions. In such a case, the interest instruction designation circuit may be configured to identify a given instruction in the sequence as an interesting instruction when execution of the given instruction causes a given event to occur and the performance monitoring circuit indicates that the occurrence of the given event has reached a threshold level. With such an approach, a synchronous exception may be triggered in response to an associated further instruction, thereby allowing the aforementioned given state information to be captured, which is then available for further analysis, for example, providing some further contextual information related to the point at which the occurrence of the given event reached a threshold level. The given state information captured when the given exception handling routine is executed may take various forms. It may be, for example, the form discussed above, providing at least one item of software-defined state associated with the execution of the given instruction of interest, such as the contents of a call stack buffer.

[0043] In one exemplary implementation, execution of a given exception handling routine in response to a further instruction associated with a given instruction reaching a given stage in the processing pipeline captures the current state of the records maintained by the performance monitoring circuitry in addition to the given state information. Thus, in addition to the given state information described above that may be captured, the contents of the records maintained by the performance monitoring circuitry, or at least a subset of the contents thereof, may also be captured when the exception handling routine triggered by the further instruction is executed.

[0044] The records maintained by the performance monitoring circuitry can take a variety of forms, but in one exemplary implementation, include a counter value for each of one or more events indicating the number of occurrences of that event since the counter value was initialized. The events tracked by the various counters can take a variety of forms and, indeed, can track any suitable metric in the system, as desired. By way of example only, one of the counters can be used to track the number of cache misses in a particular cache. For example, when a load or store instruction is executed, it can be determined whether there is a miss in the level 1 data cache, and if there is a miss, an event counter for the cache miss event can be incremented. When such counters are maintained for various events in the device, this can provide a useful performance monitoring record that can be later analyzed when attempting to analyze program execution.

[0045] Considering the cache miss example above, when execution of a load or store instruction causes the cache miss event counter to reach a threshold level, the load or store instruction can be marked as an interesting instruction, and the interesting instruction designation circuit can apply selection criteria to determine an associated further instruction that has a synchronization exception associated with it. Then, when that further instruction reaches a given stage in the pipeline, a synchronization exception is triggered, causing the aforementioned exception handling routine to be executed to collect desired device state information, and optionally also collect information about all or a subset of the counters maintained by the performance monitoring circuit.

[0046] As another exemplary use case for the techniques described herein, it may be useful to detect situations where a call stack buffer reaches a certain threshold level of fullness or emptyness. As previously mentioned, the call stack buffer may maintain information used to process transitions between subroutines, and an entry is added to the call stack buffer each time a linked branch instruction is encountered to capture information used when returning from a subroutine entered in response to the linked branch instruction. Furthermore, the most recently added entry is removed from the call stack buffer, and the information stored therein is consumed each time a return instruction is encountered. The information maintained in a call stack buffer entry may take various forms. For example, the entry may include an address associated with the caller of the subroutine (either the linked branch instruction or the target of a subroutine return, which is the next sequential instruction after the linked branch instruction) or an address associated with the called subroutine.

[0047] Whatever information is stored in the call stack buffer, the buffer is of finite size and therefore intervention may be required when the buffer reaches a full or empty threshold, e.g., when the buffer becomes full or emptied.

[0048] According to the techniques described herein, an instruction-of-interest designation circuit may be configured to identify a given instruction in a sequence as an instruction of interest when execution of the given instruction causes several entries in the call stack buffer to reach a trigger level. Further instructions for which a synchronous exception is pending are then identified, so that when the further instructions reach a given stage in the pipeline, a synchronous exception is taken to cause an exception handling routine to execute, which can then capture system state that may be useful when analyzing the state of the call stack buffer.

[0049] In one exemplary implementation, the trigger level indicates that the call stack buffer is full, and the given instruction identified as the instruction of interest is a linked branch instruction that caused the trigger level to be reached. In this case, the further instruction is a subsequent instruction flow-altering instruction of a given type. For example, of particular interest here are subsequent linked branch instructions, which attempt to add another entry to the call stack buffer when the call stack buffer is already full. However, in some exemplary implementations, it may be easier to mark the next instruction flow-altering instruction that causes any interaction with the call stack buffer as a further instruction; thus, in one exemplary implementation, the further instruction may be the first occurrence of a subsequent linked branch instruction or a subsequent return instruction. When the exception handling routine is eventually triggered by that subsequent instruction flow-altering instruction reaching a given stage in the pipeline, the exception handling routine can determine whether any intervention is required regarding the state of the call stack buffer.

[0050] Similarly, the trigger level may alternatively or additionally indicate that the call stack buffer is empty. In situations where the trigger level indicates that the call stack buffer is empty, the given instruction identified as the instruction of interest may be the return instruction that caused the trigger level to be reached. Again, the further instruction may be a subsequent instruction flow altering instruction of a given type. Of particular interest here are subsequent return instructions that may attempt to pop an entry from the stack in situations where the stack is already empty. However, for the same reasons as explained above, it may be determined to be simpler from a hardware perspective to mark the next occurrence of any instruction flow altering instruction that interacts with the call stack buffer as a further instruction, and thus mark the instruction occurring next to, for example, either a return instruction or a branch with link instruction as a further instruction.

[0051] A specific example will now be described with reference to the figures.

[0052] Figure 1 is a block diagram of an apparatus according to an exemplary implementation. A processor pipeline 10 is provided for executing a sequence of instructions fetched from memory. The processing pipeline comprises multiple stages, e.g., a fetch stage 15, a decode stage 20, an issue stage 25, and an execute stage 30 shown in Figure 1. It will be appreciated that in some systems there may be additional stages within the processing pipeline, e.g., a rename stage to facilitate register renaming in an out-of-order processor.

[0053] The fetch stage 15 is configured to issue fetch requests to memory, which are processed through the instruction cache 50 (and any intervening levels of cache, as needed) to retrieve sequences of instructions for execution. The fetch circuitry has access to specific structures to assist in determining which instructions to fetch, for example, branch prediction circuitry, which is used to predict whether a branch instruction will be taken or not taken, and possibly branch prediction circuitry, which is used to predict the target address of a taken branch.

[0054] Fetched instructions pass through a decode stage 20, where they are decoded to identify the operations that need to be performed by the processing pipeline to effectuate execution of each instruction. The decoded instructions are then passed to an issue stage 25, where they are queued awaiting dispatch to an execution stage 30. The execution stage 30 may comprise several different execution units, such as an arithmetic logic unit (ALU), a floating-point unit (FPU), a load / store unit (LSU), etc., for performing various data processing tasks. Load instructions in the fetched sequence may execute in an LSU to load data from memory through one or more caches (including data cache 55) into registers of register file 60. Similarly, store instructions may execute in an LSU to store data from registers in register file 60 back to memory (the store operation may cause the data to be cached in a cache in the cache hierarchy, such as data cache 55, rather than being written back to memory at that time).

[0055] The issue stage may be configured to dispatch instructions to the execution stage once the source operands required by the instruction become available, e.g., once those source operand values become available in the register file 60 or on some forwarding path provided to the execution stage 30.

[0056] Statistical profiling circuitry 65 may be configured to generate records containing multiple items of information regarding the execution of particular instructions in response to the execution of those instructions. A buffer 70 may be provided for storing the records generated by statistical profiling circuitry 65. The items of information captured by statistical profiling circuitry in each record may take various forms depending on the implementation, but generally are items of information regarding the execution of the instruction to which the record relates. Thus, for example, a record may capture instruction address, instruction type, execution context (e.g., at which exception level processing pipeline 10 is operating), an indication of the software process executing at that exception level (sometimes referred to as a context identifier), information regarding the latency of the instruction, etc. Such records may later be analyzed as part of a process of monitoring program execution within processing pipeline 10. Such monitoring activity may be performed in a variety of situations, for example, when attempting to debug program code or during normal operation of the processing pipeline.

[0057] Other structures can also be used to obtain useful information that can be analyzed when monitoring program execution. One example is a performance monitoring unit (PMU) 75 that can track particular events of interest that occur within the device. For example, the PMU 75 can maintain a set of counters 80, each counter associated with a particular event, and the counters incremented to track the number of occurrences of each event of interest. While events of interest can take a variety of forms, one particular example may be a counter used to track cache misses in a particular cache, such as the level 1 data cache 55 coupled to the LSU of the execution stage 30. Similar to the records generated by the statistical profiling circuitry 65, the counters 80 maintained by the PMU 75 can provide useful information when analyzing the operation of the device during program execution.

[0058] However, when analyzing such information, it may also be useful to access specific state information regarding the state of the device when a particular record was created by the statistical profiling circuitry and / or when a particular threshold in a counter was reached. Alternatively, it may be useful to obtain such state information to provide an indication of the form of that information at a particular point of interest, such as the execution of a particular instruction. The state information of interest can take various forms, but in one embodiment is at least one item of software-defined state, where such software-defined state is not typically tracked by components such as the statistical profiling circuitry 65 or the PMU 75. As a particular example, the contents of the call stack buffer 85 when a particular instruction is executed may be useful, either useful in itself or to provide additional context when analyzing information such as a record generated by the statistical profiling circuitry 65 or a counter 80 generated by the PMU 75.

[0059] The techniques described herein provide a mechanism for allowing desired state information of a device to be collected at a point in time, where the captured state information may indicate conditions that existed when an instruction of interest was executed, but does not directly interfere with the execution of the instruction of interest. In particular, an instruction-of-interest designation circuit 40 is provided that is configured to apply criteria to identify one or more instructions of interest that appear in a sequence of instructions executed within the processing pipeline 10. Instructions of interest can be selected in a variety of ways. For example, considering the statistical profiling circuit 65, each instruction used to trigger the statistical profiling circuit to generate a record may be designated as an instruction of interest by the instruction-of-interest designation circuit 40. As another example, when an instruction is executed that causes one of the events tracked by the PMU 75, and the occurrence of that instance of the event causes a corresponding counter 80 within the PMU to reach a threshold level, that instruction may also be identified as an instruction of interest.

[0060] As yet another example, an instruction that causes a change to a subroutine being executed by processing pipeline 10 may cause an entry to be pushed into or popped from call stack buffer 85, and if execution of such an instruction causes a particular full or empty threshold of call stack buffer 85 to be reached, the instruction may also be identified as an instruction of interest.

[0061] According to the techniques described herein, once an instruction of interest is identified by the instruction of interest designation circuit 40, the instruction of interest designation circuit also applies defined criteria to determine a further instruction that follows the instruction of interest in the sequence of instructions, and then marks the further instruction as having a synchronization exception associated with it.

[0062] As a result, execution of the instruction of interest proceeds unchanged, but if a further instruction arrives at a given stage in the processing pipeline and assumes that a synchronization exception is still associated with it (also referred to herein as being pending for the further instruction), this may be used to trigger a synchronization exception rather than the further instruction proceeding to execution. The given stage at which this analysis is performed may be any suitable stage within processing pipeline 10. In one exemplary implementation, it may be execution stage 30, although in alternative implementations, an earlier stage in the processing pipeline may be used as the given stage that causes a synchronization exception to be triggered when the further instruction arrives at that stage.

[0063] When a synchronous exception is triggered, it causes the processing pipeline to execute a given exception handling routine to collect state information of interest as described above, such as the contents of the call stack buffer 85. This can be stored internally or output from the device and can be combined with other information, such as an associated record generated for the instruction of interest by the statistical profiling circuitry 65, or the contents of one or more counters 80 maintained by the PMU 75, which may be useful, for example, when the instruction of interest caused an event to occur that caused one of the counters to reach a threshold level.

[0064] Due to the fact that the synchronous exception is not associated with the instruction of interest itself, this does not prevent the instruction of interest from being executed in its normal manner. However, by appropriately selecting a further instruction to be associated with the instruction of interest, it is possible to ensure that the synchronous exception is taken at a deterministic time following the execution of the instruction of interest, which can greatly enhance the usefulness of the state information collected when an exception handling routine is executed in response to the synchronous exception.

[0065] 2 is a flow diagram illustrating the operation of the instruction of interest designation circuit 40. In step 100, instructions of interest are identified by the instruction of interest designation circuit 40. As discussed above, a variety of different criteria may be used to identify each instruction of interest. For example, the instruction of interest designation circuit may monitor certain types of instructions and mark them as instructions of interest, and / or may be configured to identify every Nth instruction in a sequence as an instruction of interest.

[0066] Once the instruction of interest has been identified, defined criteria are applied in step 105 to determine further instructions that appear after the instruction of interest in the sequence of instructions. The criteria applied here can take a variety of forms, some examples of which are described below with reference to Figures 5A-5C. However, the purpose is to identify appropriate instructions so that when a synchronization exception is triggered in response to that instruction and causes some state information to be collected, that state information is likely to represent the form of the state information at the time the instruction of interest was executed, or at least be in a form in which such information can be inferred from the captured state information.

[0067] If a further instruction is identified in step 105, then in step 110 the further instruction is marked as having a synchronization exception associated with it, and the marking of the further instruction passes through the processing pipeline along with the further instruction. As will be explained in more detail below, in some example implementations, the association of the synchronization exception with the further instruction may be removed before the further instruction reaches the given stage referred to above, but assuming the synchronization exception is still pending on the further instruction by the time the further instruction reaches the given stage, this will trigger the synchronization exception and cause the exception handling routine mentioned above to be executed to collect given state information.

[0068] This is shown in more detail with respect to Figure 3. In particular, in step 150 it is determined whether a further instruction has reached a given stage of the processing pipeline and is still marked as having a synchronization exception associated with it. As mentioned above, the given stage may be, for example, execution stage 30, but may alternatively be an earlier stage in the processing pipeline.

[0069] If, in step 150, it is determined that a further instruction has reached a given stage and a synchronous exception is marked as pending, then a synchronous exception is triggered in step 155. This causes the processing pipeline to stop executing the fetched instruction and instead execute an exception handling routine to collect given state information in step 160. The exact exception handling routine that is executed typically depends on the type of synchronous exception, and therefore the synchronous exception triggered in step 155 is used to determine the particular exception handling routine that needs to be executed.

[0070] Once the given state information has been collected by the exception handling routine in step 165, it may be output from the device or stored in some suitable internal storage structure of the device for later analysis. Processing then returns from the exception handling routine in step 170, and execution of the instruction stream may resume. At this point, execution of further instructions may proceed. This may occur immediately after returning from the exception handling routine, for example, if the given stage at which the synchronous exception was triggered was the execute stage, or one or more other instructions may be executed first, and then pass through the remainder of the processing pipeline until the further instructions reach the execute stage, at which point the further instructions may be executed.

[0071] 4 schematically illustrates one form of state information that may be usefully captured by the techniques described herein. In particular, the state information may include the contents of a call stack buffer 85. The call stack buffer is used to maintain information for processing transitions between subroutines, and an entry is added to the call stack buffer each time a branch with link (BL) instruction is encountered to capture information that will eventually be used when returning from a subroutine entered in response to that BL instruction. Such an action is typically referred to as pushing an entry into the call stack buffer. Furthermore, the most recently added entry is removed, and the information stored therein is consumed, each time a return instruction is encountered; such an action is typically referred to as popping an entry from the stack.

[0072] The information pushed onto the call stack buffer in response to a BL instruction can take a variety of forms, provided it indicates sufficient information to enable a subsequent return from the subroutine branched to by the BL instruction. In the example shown in FIG. 4, each time a BL instruction is encountered, the return address of the subroutine being branched to by the BL instruction is pushed onto the call stack buffer. A call stack pointer is maintained to identify the top entry of the call stack buffer at any particular time. Thus, considering FIG. 4, assume that subroutine A is initially executing and then, at point 200, encounters a BL instruction that causes a transition to subroutine B. This causes the return address of subroutine A (i.e., the address of the next instruction to be executed in subroutine A when processing eventually returns to subroutine A) to be pushed onto the entry of the call stack pointed to by the current call stack pointer. Furthermore, the call stack pointer is incremented, and processing branches to subroutine B. As indicated by points 205 and 210, several subroutines are nested in this example, and therefore, each time a subroutine is changed by a BL instruction, an additional return address entry is pushed onto the call stack buffer 85. Thus, at point 205, the return address of subroutine B is pushed onto the call stack, the call stack pointer is incremented, and processing branches to subroutine C. Similarly, at point 210, the return address of subroutine C is pushed onto the call stack, the call stack pointer is incremented, and processing continues to subroutine D.

[0073] At this point, the contents of call stack buffer 85 appear as shown in Figure 4. In particular, there are three entries storing the return addresses for subroutines A, B, and C, and the call stack pointer has been incremented to point to the next empty entry. When point 215 is reached, a return instruction is encountered indicating that subroutine D has completed. At this point, the call stack pointer is decremented, and then the entry pointed to by the call stack pointer is popped from the call stack. This information provides the return address for subroutine C, allowing processing to return to execution of subroutine C. At this point, the entry containing the return address of subroutine C has been popped, and its information has been consumed; note that this information would not normally be overwritten at that point. However, because the current call stack pointer still points to that entry, when a subsequent BL instruction is encountered, it will overwrite the return address information for subroutine C by pushing a new return address onto the call stack in the entry pointed to by the call stack pointer.

[0074] Assume that in step 220, another return instruction is encountered, decrementing the call stack pointer and popping the return address currently pointed to by the call stack pointer, i.e., the return address of subroutine B. Processing then returns to subroutine B.

[0075] As an example, if an instruction of interest occurs at point 217 in subroutine D, it may be desirable to capture the contents of the call stack buffer as they were when the instruction of interest was executed. As previously explained, this is in the form of call stack buffer 85, as shown in FIG. 4. However, if another BL instruction is encountered before the contents of the call stack buffer are collected, a new entry is pushed into the call stack buffer, and the contents of the call stack buffer are modified. Similarly, if one or more return instructions are encountered, an entry is popped from the call stack and the call stack pointer is decremented. While the popped information is not immediately overwritten, the current call stack pointer at least no longer corresponds to the call stack pointer as it existed at point 217. Furthermore, as shown at point 225, if a subsequent BL instruction is encountered and occurs before the exception handling routine is triggered to capture the call stack buffer state information, this may overwrite the contents of the call stack buffer that existed at point 217, such that it can no longer be determined.

[0076] According to the techniques described herein, the likelihood of such a scenario occurring can be reduced by appropriately selecting the further instruction that follows the instruction of interest and thus causes the triggering of a synchronization exception. Three possible exemplary approaches are shown in Figures 5A-5C. According to Figure 5A, once the instruction of interest is identified in step 250, processing proceeds to step 255, where the instruction of interest designation circuit 40 identifies the instruction that executes immediately after the instruction of interest as the further instruction. This therefore avoids the possibility of processing transitioning to a different subroutine before the state of the call stack buffer has been captured.

[0077] However, in some cases, it may be determined that it is not appropriate to mark the immediately following instruction as a further instruction. For example, out-of-order execution of instructions may be supported, and the immediately following instruction may normally be allowed to execute before the instruction of interest. However, by designating the immediately following instruction as a further instruction, and therefore withholding a synchronization exception for it, this may prevent such reordering and introduce a probe effect. If this is deemed to be a problem, it can be mitigated by withholding a synchronization exception for the Nth instruction following the instruction of interest, where N is greater than 1.

[0078] As another example of a technique that may be used to select a further instruction, as shown in FIG. 5B , when an instruction of interest is identified in step 260, the interest instruction designation circuit 40 may be configured to identify the next return instruction as the further instruction. If there is no other BL instruction occurring before the next return instruction, this ensures that a synchronous exception occurs while still in the same subroutine. However, by identifying the next return instruction as the further instruction, even if another BL instruction occurs and a new entry is pushed onto the stack, this ensures that the call stack pointer is not decremented below its value when the instruction of interest occurred, thus avoiding the risk of overwriting the associated call stack contents that existed at the time of the instruction of interest.

[0079] 5C, when an instruction of interest is identified in step 270, the instruction specification circuit 40 can identify the next BL instruction as the further instruction in step 275. This ensures that the first encounter of one or more return instructions and the decrement of the call stack pointer will not overwrite the call stack contents before the synchronous exception is taken. Thus, by the above-described means, it is possible to allow the instruction of interest to be executed normally, but provide a deterministic point at which the synchronous exception is taken, and to analyze the contents of the call stack buffer before its contents are modified in a way that prevents the contents of the call stack buffer from being determined when the instruction of interest is executed.

[0080] As another exemplary approach that can be taken to determine the further instruction, the instruction designation circuit 40 can identify any instruction that appears in the sequence of instructions after the instruction of interest as a further instruction, up to but not beyond the next instruction of a given type. In this case, the actual instruction selected as the further instruction is not considered critical if it is an instruction up to but not beyond the instruction of a particular type that appears after the instruction of interest. For example, the designated type here could be a BL instruction; thus, such an approach ensures that a synchronization exception will occur at least by the time the next BL instruction is encountered, without strictly restricting which instructions may have a synchronization exception pending.

[0081] 6 is a flow diagram illustrating how the techniques described herein may be used in connection with statistical profiling, such as may be performed by statistical profiling circuitry 65. In step 300, selection criteria are applied to identify the next instruction of interest, the selection criteria being applied by instruction of interest designation circuitry 40. In an example of statistical profiling, several criteria may be used, for example, the criteria may simply select every Nth instruction in a sequence, or may look for a particular type of instruction to be flagged as an instruction of interest.

[0082] In step 305, a further instruction is identified by the instruction of interest designation circuit 40, and the next instruction is marked as having a synchronization exception associated with it. Any suitable scheme can be used to select the further instruction, such as, for example, using the techniques described above with reference to Figures 5A-5C.

[0083] In step 310, when the instruction of interest is executed, the statistical profiling circuitry may collect multiple items of information regarding the execution of the instruction of interest and store the collected information as a record in buffer 70. Various types of information that may be collected at this time have already been described above, such as instruction address, instruction type, execution context, etc. In one particular exemplary implementation, the usual information collected may be supplemented with one or more additional items of information, such as the current call stack pointer value when the instruction of interest was executed. Collecting the current call stack pointer value may assist in time when attempting to analyze the contents of a call stack buffer obtained when an exception handling routine later executes, for example, by enabling a comparison of the call stack pointer value with the call stack pointer value that exists when the exception handling routine executes.

[0084] In step 315, when a further instruction reaches a given stage as previously mentioned, a synchronous exception is taken and a corresponding exception handling routine is executed to collect specific state information not present in the record stored in buffer 70. As previously explained, this may be specific software-defined state, such as the contents of call stack buffer 85.

[0085] In step 320, this extra state information is output or stored in association with the record of the instruction of interest, and then in step 325, processing returns to the exception handling routine to allow further instructions to be executed.

[0086] Collecting this extra state information can provide additional useful context information when analyzing the record produced by the statistical profiling circuitry for the instruction of interest. For example, by using the contents of the call stack buffer that existed when the instruction of interest was executed, it is possible to identify the sequence of subroutines that were executed before the instruction of interest was reached.

[0087] If the further instruction is selected to be the next BL or return instruction that appears following the instruction of interest, this can ensure that when the exception handling routine executes to capture the call stack buffer contents, processing is still within the same subroutine that encountered the instruction of interest. However, in situations where another criterion is selected to select further instructions, such as only the next return instruction or only the next BL instruction, the call stack contents may have changed, but it can still be ensured that none of the original call stack contents that existed when the instruction of interest was executed have been overwritten. In such situations, by capturing the current call stack pointer value when the instruction of interest was executed in the record generated by the statistical profiling circuitry, it is possible to determine the exact shape of the call stack buffer when the instruction of interest was executed. In particular, by comparing the call stack pointer value maintained in the record with the call stack pointer value that exists when the call stack buffer is analyzed by the exception handling routine, it is possible to recreate the shape of the call stack buffer when the instruction of interest was executed.

[0088] FIG. 7 is a flow diagram illustrating an alternative approach that can be used when performing statistical profiling using the techniques described above. According to the scenario illustrated in FIG. 7, the instruction-of-interest designation circuit 40 includes a filter circuit 45 that can be used to reduce the number of instructions of interest and, therefore, the number of synchronization exceptions made. In particular, as shown in FIG. 7, the instruction-of-interest designation circuit 40 can apply initial selection criteria to identify candidate instructions of interest in step 350. This can include, for example, selecting every Nth instruction in a sequence. Then, in step 355, further selection criteria can be applied to evaluate whether the candidate instructions of interest should be treated as actual instructions of interest, at least up to the time the candidate instructions of interest were executed.

[0089] The time at which this further selection criteria is applied may vary depending on the implementation. For example, it may be done in advance to exclude certain types of instructions from being interesting instructions. Thus, the initial selection criteria may select every Nth instruction, while the further selection criteria may examine the type of each such selected candidate instruction of interest and exclude certain types of instructions known to be particularly uninteresting from further consideration. Alternatively or additionally, candidate instructions of interest may be allowed to proceed through the pipeline to the execution point, but the behavior of those instructions at runtime may be analyzed to determine whether they are still interesting and therefore should be retained as actual instructions of interest.

[0090] As a particular example, it may be determined that only relatively slow load or store instructions are of interest. Thus, initial filtering in step 355 may remove from further consideration any instructions that are not load or store instructions, and later filtering at runtime may filter out any load or store instructions that executed relatively quickly, retaining only the slow-executing load or store instructions as actual instructions of interest.

[0091] In step 360, it is determined that the record in buffer 70 will be maintained only if the candidate instruction of interest is to be treated as an actual instruction of interest. Thus, upon execution of the candidate instruction of interest, statistical profiling circuit 65 may perform a process to gather various information that is stored in the record, but if it is determined that the candidate instruction of interest is no longer of interest, the record will not be maintained.

[0092] In step 365, it is determined whether a record is maintained to determine what steps to take in relation to the further instruction. As previously mentioned, the given stage at which the further instruction is evaluated may be the execution stage or may be an earlier stage in the pipeline. In situations where the given stage is earlier in the pipeline, it may be the case that processing of further instructions is paused at that given stage until it is known whether a record is maintained for the instruction of interest.

[0093] If a record is maintained, the process proceeds to step 370, and when a further instruction reaches the given stage, a synchronous exception is taken and the process proceeds as in the remainder of FIG. 6 (i.e., performing steps 315, 320, and 325).

[0094] However, if no record is maintained, when a further instruction reaches the given stage, the synchronization exception is not taken and the further instruction is allowed to proceed to execute normally in step 375 .

[0095] In situations where a decision as to whether to maintain a record for an instruction of interest is made before the further instruction reaches a given stage, in one exemplary implementation, the synchronization exception may remain pending for the further instruction, but may be ignored when the further instruction reaches a given stage if it is determined that a record is not being maintained. Alternatively, if it is determined that a record is not being maintained, the synchronization exception may be removed from the further instruction, so that by the time the further instruction reaches a given stage, the synchronization exception is no longer pending and therefore simply proceeds to execution without the exception being taken.

[0096] 8 is a flow diagram illustrating a performance monitoring technique that can be used when utilizing the techniques described above. In step 400, the PMU 75 maintains event counters 80 for a number of events. In step 405, it is determined whether execution of the instruction causes one of the monitored events to occur; if not, no further action is required in step 420. However, if execution of the instruction does cause a monitored event to occur, the associated counter is updated in step 410, and in step 415, it is evaluated whether a threshold level has been reached for that counter. If not, no further action is required in step 420.

[0097] However, if it is determined in step 415 that the threshold level has been reached, the instruction that caused the monitored event to occur is treated as an instruction of interest in step 425. Accordingly, a further instruction is identified for that instruction of interest, and that further instruction is marked as having a synchronization exception associated with it.

[0098] When a further instruction reaches a given stage, a synchronous exception is taken in step 430, and an exception handling routine is executed to collect certain state information, which can take a variety of forms, for example, software-defined state such as the contents of the call stack buffer described above.

[0099] In step 435, this additional state information is output or stored in association with the current counter values of the monitored events as maintained by the PMU, thus providing additional context information that can be used when analyzing those counter values.

[0100] In step 440, it may be optionally decided to reset one or more counters. For example, it may be appropriate to at least reset a counter that has reached a threshold level. Furthermore, processing returns from the exception handling routine, allowing further instructions to proceed with execution.

[0101] FIG. 9 is a flow diagram illustrating a further exemplary use case of the techniques described herein for tracking when the call stack buffer reaches a full or empty threshold level. In step 450, when a BL instruction is executed, it is determined whether the execution of the BL instruction will cause the call stack buffer to become full. If so, in step 465, the BL instruction is marked as an instruction of interest, and in the example shown in FIG. 9, the next linked branch or return instruction (whichever occurs first) is marked as a further instruction with a synchronization exception pending thereon. Of particular interest is the next BL instruction that occurs before the intervening return instruction, since an attempt is made to add further entries to the call stack buffer when it is already full. However, for procedural efficiency, it may be easier to simply mark either the next BL or return instruction in the instruction sequence as a further instruction. Alternatively, only the next BL instruction may be used as a further instruction.

[0102] If it is determined in step 450 that the BL instruction does not fill the call stack buffer, it is determined in step 455 whether a return instruction that would empty the call stack buffer has been executed. If not, the process returns to step 450.

[0103] However, if it is determined that a return instruction that empties the call stack buffer has been executed, then in step 460 the return instruction is marked as an instruction of interest, and in the example shown in FIG. 9 , the next return or BL instruction is marked as a further instruction with a synchronous exception pending. Of particular interest is a scenario in which a return instruction that empties the call stack buffer is followed by another return instruction that attempts to pop an entry from the call stack buffer when the call stack buffer was empty. However, for procedural efficiency, it may be easier to simply mark whichever next return or BL instruction occurs first following the instruction of interest. Alternatively, the interest instruction designation circuit 40 may be configured to look only for the next return instruction following the instruction of interest and mark it as a further instruction.

[0104] FIG. 10 illustrates a simulator implementation that may be used. While the foregoing examples embody the present invention in terms of apparatus and methods for operating specific processing hardware that supports the techniques, it is also possible to provide an instruction execution environment according to the examples described herein, which is implemented using a computer program. Such computer programs are often referred to as simulators, insofar as they provide a software-based implementation of a hardware architecture. Various simulator computer programs include emulators, virtual machines, models, and binary translators, including dynamic binary translators. Typically, a simulator implementation may run on a host processor 515, which optionally runs a host operating system 510 that supports the simulator program 505. In some configurations, there may be multiple layers of simulation between the hardware and the provided instruction execution environment, and / or multiple different instruction execution environments may be provided on the same host processor. Historically, powerful processors have been required to provide simulator implementations that run at reasonable speeds, but such an approach may be justified in certain situations, such as when it is desirable to execute code native to another processor for compatibility or reuse reasons. For example, a simulator implementation may provide an instruction execution environment with additional features not supported by the host processor hardware, or may provide an instruction execution environment typically associated with a different hardware architecture. An overview of simulation is given in "Some Efficient Architecture Simulation Techniques," Robert Bedichek, Winter 1990, USENIX Conference, pp. 53-63.

[0105] To the extent that examples are described above with reference to particular hardware constructs or features, equivalent functionality may be provided in a simulated implementation by suitable software constructs or features. For example, particular circuits may be implemented as computer program logic in a simulated implementation. Similarly, memory hardware such as registers or caches may be implemented as software data structures in a simulated implementation. Also, the physical address space used to access memory in a hardware device may be emulated as a simulated address space, which is mapped by simulator 505 to a virtual address space used by host operating system 510. In configurations where one or more of the hardware elements referred to in the preceding examples reside in host hardware (e.g., host processor 515), some simulated implementations may use the host hardware, if appropriate.

[0106] The simulator program 505 may be stored on a computer-readable storage medium (which may be a non-transitory medium) and provides a virtual hardware interface (an instruction execution environment) to the target code 500 (which may include applications, guest operating systems, and a hypervisor), where this virtual hardware interface is the same as the hardware interface of the hardware architecture modeled by the simulator program 505. Thus, the program instructions of the target code 500 may be executed from within the instruction execution environment using the simulator program 505, thereby enabling a host computer 515, which does not actually have the hardware features of the aforementioned devices, to emulate these features. The simulator program may include processing program logic 520 for emulating the operation of the processing pipeline 10 and interest instruction specifier program logic 525 for emulating the operation of the interest instruction specifier circuit 40. The system's architectural registers 60 may also be emulated using data structure emulating program logic (not shown) maintained by the simulator code 505 for mapping the architectural registers of the target architecture to the memory space used by the host hardware 515. Thus, the techniques described herein for collecting device state information may be performed in software by simulator program 505 in the example of FIG.

[0107] In this application, the term "configured to..." is used to mean that elements of an apparatus have a configuration that is capable of performing a defined operation. In this context, "configuration" refers to a way of arranging or interconnecting hardware or software. For example, an apparatus may have dedicated hardware that provides the defined operation, or a processor or other processing device may be programmed to perform the function. "Configured to" does not imply that the apparatus elements need to be modified in any way to provide the defined operation.

[0108] Although illustrative embodiments of the invention have been described in detail herein with reference to the accompanying drawings, it will be understood that the invention is not limited to those precise embodiments, and that various changes, additions, and modifications may be made by those skilled in the art without departing from the scope and spirit of the invention as defined by the appended claims. For example, various combinations of the features of the independent claims may be made with the features of the dependent claims without departing from the scope of the invention.

Claims

1. 1. An apparatus comprising: a processing pipeline for executing a sequence of instructions; an instruction of interest designation circuit for identifying at least one of the instructions in the sequence as an instruction of interest, each instruction of interest being an instruction for which given state information of the device associated with execution of the instruction of interest should be collected; Equipped with the interest instruction designation circuitry is configured to, for each identified interest instruction, apply defined criteria to determine a further instruction that follows the interest instruction in the sequence of instructions and mark the further instruction as having a synchronization exception associated therewith; wherein the processing pipeline, in response to the further instruction reaching a given stage of the processing pipeline and being marked as having the synchronization exception associated therewith, triggers the synchronization exception instead of executing the further instruction, thereby causing the processing pipeline to execute a given exception handling routine to collect the given state information.

2. 2. The apparatus of claim 1, wherein upon return from the given exception handling routine, the processing pipeline is configured to execute the further instruction.

3. 3. Apparatus according to claim 1 or 2, wherein the defined criteria cause the interesting instruction designation circuit to determine as the further instruction an instruction that appears in a predetermined position in the sequence of instructions relative to the interesting instruction.

4. The apparatus of claim 3 , wherein the defined criteria causes the instruction of interest designation circuit to determine as the further instruction the instruction immediately following the instruction of interest in the sequence of instructions.

5. 3. The apparatus of claim 1, wherein the defined criteria causes the interest instruction designation circuit to determine as the further instruction at least one instruction of a given type that appears in the sequence of instructions after the interest instruction.

6. 6. The apparatus of claim 5, wherein the at least one instruction of a given type is a return instruction used to return the processing pipeline to execution of program code that was executing prior to execution of a current subroutine.

7. 7. Apparatus according to claim 5 or 6, wherein the at least one instruction of a given type is a branch-and-link instruction which, when executed, causes the processing pipeline to stop processing a current subroutine and begin executing a further subroutine.

8. 3. The apparatus of claim 1, wherein the defined criteria cause the interest instruction designation circuit to determine as the further instruction any instruction that appears in the sequence of instructions after the instruction of interest, up to but not more than a next instruction of at least one given type that appears in the sequence of instructions after the instruction of interest.

9. a statistical profiling circuit responsive to execution of a given instruction of interest to generate a record including a plurality of items of information regarding said execution of said given instruction of interest; 9. The apparatus of claim 1, wherein the given state information collected by executing the given exception handling routine includes additional information not included in the record generated by the statistical profiling circuitry.

10. The apparatus of claim 9 , wherein the additional information includes at least one item of software-defined state associated with execution of the given instruction of interest.

11. The apparatus of claim 10 , wherein the at least one item of software-defined state includes the contents of a call stack buffer maintained by the apparatus.

12. 12. The apparatus of claim 11, wherein the statistical profiling circuitry is configured to include, within the plurality of items of information regarding the execution of the given instruction of interest, an indication of a current call stack buffer pointer value at the time the given instruction of interest was executed.

13. 13. The apparatus of claim 9, wherein the instruction of interest designation circuitry is configured to apply selection criteria to identify each instruction of interest for which the statistical profiling circuitry should record the plurality of information items when the instruction of interest is executed.

14. the selection criteria include initial selection criteria and further selection criteria; the instruction of interest designation circuitry is configured to apply the initial selection criteria to identify candidate instructions of interest; the instruction of interest designation circuitry comprises a filter circuitry that applies the further selection criteria to determine which candidate instructions of interest should be used as the instructions of interest; 14. The apparatus of claim 13.

15. The apparatus of claim 14 , wherein the filter circuitry is configured to treat a candidate instruction of interest as an instruction of interest only if the type of the candidate instruction of interest is one or more given types of instructions.

16. 16. Apparatus according to claim 14 or 15, wherein the filter circuitry is configured to treat a candidate instruction of interest as an instruction of interest if a given behaviour is observed when the candidate instruction of interest is executed.

17. 17. The apparatus of claim 16, wherein the statistical profiling circuitry obtains the plurality of information items regarding the execution of a given candidate instruction of interest in response to the execution of the given candidate instruction of interest, but maintains the record including the plurality of information items only if the filter circuitry determines that the given behavior has been observed.

18. 18. Apparatus according to any one of claims 14 to 17, wherein only when a candidate instruction of interest is treated as an instruction of interest by the filter circuitry is the associated further instruction marked as having a synchronization exception associated with it when the further instruction reaches the given stage of the processing pipeline.

19. a performance monitoring circuit that maintains a record indicative of the occurrence of one or more events during execution of the sequence of instructions; the interest instruction designation circuitry is configured to identify a given instruction in the sequence as an interest instruction when execution of the given instruction causes a given event to occur and the performance monitoring circuitry indicates that the occurrence of the given event has reached a threshold level; 19. Apparatus according to any one of claims 1 to 18.

20. 20. The apparatus of claim 19, wherein execution of the given exception handling routine in response to the further instruction associated with the given instruction reaching the given stage of the processing pipeline captures a current state of the record maintained by the performance monitoring circuitry in addition to the given state information.

21. 21. The apparatus of claim 19 or 20, wherein the record maintained by the performance monitoring circuitry includes, for each of the one or more events, a counter value indicating the number of occurrences of the event since the counter value was initialized.

22. a call stack buffer for maintaining information used to process transitions between subroutines, wherein an entry is added to the call stack buffer each time a linked branch instruction is encountered to capture information used when returning from a subroutine entered in response to the linked branch instruction, and wherein the most recently added entry is removed and the information stored therein is consumed each time a return instruction is encountered; the interest instruction designation circuitry is configured to identify a given instruction in the sequence as an interest instruction when execution of the given instruction causes some entries in the call stack buffer to reach a trigger level; 22. Apparatus according to any one of claims 1 to 21.

23. the trigger level indicates that the call stack buffer is full; the given instruction identified as the instruction of interest is a linked branch instruction that causes the trigger level to be reached; the further instruction is a subsequent instruction flow altering instruction of a given type, 23. The apparatus of claim 22.

24. the trigger level indicates that the call stack buffer is empty; the given instruction identified as the instruction of interest is a return instruction that causes the trigger level to be reached; the further instruction is a subsequent instruction flow altering instruction of a given type, 24. Apparatus according to claim 22 or 23.

25. 1. A method executed by a device for collecting given state information of said device, comprising: using a processing pipeline for executing a sequence of instructions; identifying at least one of the instructions in the sequence as an instruction of interest, each instruction of interest being an instruction for which given state information of the device associated with execution of the instruction of interest is to be collected; Including, for each of the identified instructions of interest, applying defined criteria to determine a further instruction that follows the instruction of interest in the sequence of instructions, and marking the further instruction as having a synchronization exception associated therewith; in response to the further instruction reaching a given stage of the processing pipeline and being marked as having the synchronization exception associated therewith, triggering the synchronization exception instead of executing the further instruction, thereby causing the processing pipeline to execute a given exception handling routine to collect the given state information; A method comprising:

26. 1. A computer program for controlling a host data processing device to provide an instruction execution environment, comprising: processing program logic for executing a sequence of instructions in a series of pipeline stages; instruction-of-interest designation program logic for identifying at least one of the instructions in the sequence as an instruction of interest, each instruction of interest being an instruction for which given state information associated with execution of the instruction of interest should be collected; Equipped with the interesting instruction designation program logic is configured to, for each identified interesting instruction, apply defined criteria to determine a further instruction that follows the interesting instruction in the sequence of instructions and mark the further instruction as having a synchronization exception associated therewith; wherein the processing program logic, in response to the further instruction reaching a given pipeline stage and being marked as having the synchronization exception associated therewith, triggers the synchronization exception instead of executing the further instruction, thereby causing the processing program logic to execute a given exception handling routine to collect the given state information.

Images