You may notice in the source code views that some lines are not coloured to indicate visited, not visited or hook failure. There's a couple of possible reasons for this:
•The source code has not been compiled due to conditional compilation using compiler pragmas or #if, #ifdef, #ifndef statements
Or, if using map files with line information:
•The compiler map file did not include object code addresses for the lines that are not coloured
When this happens, Performance Validator has no way of accurately determining which object code corresponds to the source code, and so can't hook the object code.
For example, here's a few lines of code:
This shows that line 831 has not been hooked, whilst all those around it have been hooked (and in the example shown, all have been visited). If we now examine the part of the MAP file for the appropriate executable.
There's no entry for line 831, which is why Performance Validator couldn't provide a hook to verify if the line was executed.
At present we don't know why the compiler map file omits information for source code lines that are clearly part of the executable image, and which are identified in the PDB debugging information.
When you find this happening, change the line hooking options so that map files are only used when PDB files can't be found, i.e. use the Use MAP when no PDB option.
|
Performance Validator instruments lines in your application by inserting code to recognise the execution of the start of every line in your application.
Before inserting the code, checks are made to ensure that it is safe to re-write the function lines.
If it is not safe to re-write the lines, they can't be instrumented.
The following items can prevent the function from being hooked:
•Function too short to hook. The function must be at least 5 bytes in length •The code for the line is too short to hook. The code for the line must be at least 5 bytes in length •Function cannot be disassembled •Instruction sequence cannot be hooked
You can improve the likelihood of your function being hooked by enabling the check boxes on the Hook Control settings.
See also the instrumentation logging which details reasons why some code is not instrumented
|
Performance Validator instruments functions in your application by re-writing the prologue and epilogue of each function in your application, inserting code to monitor performance information.
Before inserting the code, checks are made to ensure that it is safe to re-write the function prologue and epilogue.
If it is not safe to re-write the function epilogue and prologue the function cannot be instrumented.
The following items can prevent the function from being hooked:
•Function too short to hook •Function has multiple exits •Function has jumps into epilogue •Function has jumps into prologue •Function cannot be disassembled •Instruction sequence cannot be hooked
You can improve the likelihood of your function being hooked by enabling the check boxes on the Hook Control settings.
See also the instrumentation logging which details reasons why some code is not instrumented
|