Patent Publication Number: US-8977916-B2

Title: Using data watchpoints to detect unitialized memory reads

Description:
TECHNICAL FIELD OF THE INVENTION 
     The technical field of this invention is embedded memory debug testing. 
     BACKGROUND OF THE INVENTION 
     Uninitialized memory reads (UMRs) are a common issue encountered by software programmers and often times difficult to track down. There are many situations where a UMR might be encountered, but ultimately a UMR is defined as a read from a location in memory that has not been initialized. 
     Some scenarios which might result in a UMR are read requests that:
         Access a memory location that has been allocated, but has not yet been initialized.   Access locations that are beyond the end of an allocated block of memory.   Attempt to access a location that has not yet been allocated.   Access a location in memory that was previously allocated but subsequently freed (or reallocated and moved).   Access a random location in memory.       

     An example in C of the scenario described above in “Access a memory location that has been allocated, but has not yet been initialized”: 
     
       
         
           
               
               
             
               
                   
                   
               
             
            
               
                   
                 struct umr_test { 
               
               
                   
                  int  element; 
               
               
                   
                 } 
               
               
                   
                 void main ( ) 
               
               
                   
                 { 
               
               
                   
                  struct umr_test *pinst; 
               
               
                   
                  pinst  =  (struct  umr_test  *)malloc (sizeof (struct 
               
               
                   
                 umr_test)); 
               
               
                   
                  printf(“pinst-&gt;element  =  %d\n”,  pinst-&gt;element); 
               
               
                   
                 // UMR occurs here 
               
               
                   
                  return; 
               
               
                   
                 } 
               
               
                   
                   
               
            
           
         
       
     
     Typically when one thinks of how UMRs occur they think of a processor executing an instruction sequence. It is important to note that a UMR can be the result of a read request by any master in a system, including DMAs, and peripherals. 
     One approach in the prior art is to establish a ‘watch’ at various locations in memory. Once a watch is established, it is assumed that the memory locations it is monitoring are uninitialized. Subsequent accesses to the watched memory locations are monitored with a ‘write’ causing the associated address to be treated as initialized. If a watch detects a read access to a location that is uninitialized, then the equivalent of a UMR is triggered. 
     The disadvantage of this approach is the reliance on hardware tracking the state of specific memory addresses or memory regions. This can result in a large amount of extra hardware, usually on the order of 1 register per address being watched. 
     In another approach known in the prior art reserved/unused encodings of a memory&#39;s ECC (Error Correction Codes) are used to detect UMRs. The ECCs within a memory are initialized by Built in Self Test (BIST) logic to a state that is defined to mean ‘uninitialized’. When a memory is written, the ECC will be overwritten with a setting different from the ‘uninitialized’ encoding. If a memory is read with an ECC value indicating that the memory has not yet been written then a breakpoint or interrupt will be generated. The disadvantage to this approach is that it is only functional with memories that support ECC. 
     SUMMARY OF THE INVENTION 
     The proposed invention uses a data watch point to monitor all read data cycles for a specific value that was set by debug tools. The value that is being watched for is pre-determined and represents uninitialized memory. This value is referred to as UMR_DATA_VALUE from here on. 
     At the beginning of a UMR debug session, all memory in a system will be initialized with UMR_DATA_VALUE. In systems where this is not practical, some subset of memory defined as part of a debug session as needing to detect a UMR is initialized with UMR_DATA_VALUE. 
     As part of program execution, whenever allocated memory is freed, the contents of that freed memory would need to be initialized with UMR_DATA_VALUE. 
     Data watch points need to be strategically deployed to key monitoring points in a system&#39;s bus topology. The data watch point monitors the read data cycles of the bus infrastructure that it is attached to. When the data watch point detects a match between the value observed during a read data cycle and the UMR DATA VALUE it triggers a debug sequence. During the debug sequence, information associated with the read data cycle is captured and then some action is taken 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       These and other aspects of this invention are illustrated in the drawings, in which: 
         FIG. 1  illustrates the UMR initialization flow; 
         FIG. 2  illustrates the UMR Watch Point flow. 
     
    
    
     DETAILED DESCRIPTION OF PREFERRED EMBODIMENTS 
     The proposed invention uses a data watch point to monitor all read data cycles for a specific value that was set by debug tools. The value that is being watched for is pre-determined and represents uninitialized memory. This value is referred to as UMR_DATA_VALUE from here on. 
     Because this invention relies on a specific data value to represent uninitialized memory there is a possibility that this data watch point solution will detect a UMR at a location that happened to have been initialized with a value that matches UMR_DATA_VALUE. Statistically, with an 8-bit read transaction, this will happen 1 in 256 reads. With a 32-bit the likelihood is much less at 1 in ˜4 billion. 
       FIG. 1  shows the initialization of the memory at the beginning of a UMR debug session. All memory in the system will be initialized with the UMR_DATA_VALUE. In systems where this is not practical, some subset of memory defined as part of a debug session as needing to detect a UMR is initialized with UMR_DATA_VALUE. 
     As part of program execution, whenever allocated memory is freed, the contents of that freed memory would also need to be initialized with UMR_DATA_VALUE. 
     With this invention, data watch points would need to be strategically placed to key monitoring points in a system&#39;s bus topology. The data watch point monitors the read data cycles of the bus infrastructure that it is attached to. When the data watch point detects a match between the value observed during a read data cycle and the UMR_DATA_VALUE it triggers a debug sequence. During the debug sequence, information associated with the read data cycle is captured and then some action is taken. 
     The type of data that is captured when a debug sequence is triggered includes: read address, initiator ID, and a timestamp. Additional data which is relevant only to specific instances of a watch point might also be captured. For instance, a data watch point deployed within a DSP might include PC and a task ID. 
     A debug sequence is completed with a debug action that signals a UMR. The debug action that is taken depends on the context of the data watch point that triggered, or the nature of the debug session. Examples of debug actions include: halting one or more central processing units (CPUs), generating an interrupt to a processor, and generating a trace message. 
     Many systems support multiple sizes for read transactions with different alignments. It is desirable in such systems to use a UMR_DATA_VALUE where every byte-lane is identical. For instance, in a system that needs to support 8-bit, 16-bit, 32-bit, and 64-bit data reads, UMR_DATA_VALUE could be CCCC_CCCC_CCCC_CCCCh. 
       FIG. 2  shows a flow chart of the UMR watch point operation. UMR logic  201  detects a memory read data cycle, and in  202  compares the data value with the UMR_DATA_VALUE. A possible match is detected in  203 . If there is no match, there is no action needs to be taken in  208 . In case of a match debug information is captured in  204 , and selected action is taken in blocks  205 ,  206  or  207 .