Please enable JavaScript to view this site.

Performance Validator Help

Navigation: The User Interface > Settings > Data Collection Settings > Instrumentation

Hook Control

Scroll Prev Top Next More

 

The Hook Control page allows you to specify how some of the more 'awkward' lines of code are hooked.

 

hook-control-settings

 

 

Most of these options are fairly advanced. They are also enabled by default, but as usual, we provide the ability to control the settings if needed.

 

 

Hook Control

 

Some lines of code are trickier to hook than others. By default Performance Validator is quite zealous in performing the safety checks and enabling hooking of these lines.

 

If necessary, you can choose not to enable these hooks.

 

The options are:  

 

Hook 32 bit relative JMP instructions instructionStep hooks lines with JMP instructions in them

 

Hook return (RET and RETN) instructions instructionStep hooks lines with RET or RETN instructions in them

 

Hook short branches (Jcc) if possible instructionStep hooks lines with short branches in them

 

 (Jcc is a conditional jump)

 

Hook long branches (Jcc) if possible instructionStep hooks lines with long branches in them

 

Detect end of functions with extra tests instructionStep perform extra tests when identifying the end of function, to avoid overwriting the code for any function that follows.

 

 

Programming Language Return Hook Behaviour

 

Different computer languages allow different constructs. For example most languages only permit one entry point per function, but FORTRAN allows many entry points per function.

 

When there are multiple entry points per function in the debugging information, it looks like there are functions that overlap each other. This can also happen in the C runtime internals (implemented in assembler). For the C runtime internals overlapped functions must not be instrumented as they often include jump tables but there is no indication in the debugging information that the jump table is present - instrumenting overlapped C runtime functions typically results in damaged code. For Fortran this isn't the case as the compiler generates the entry points without jump tables in the middle of the code - instrumenting overlapped Fortran functions is safe.
 
To correctly handle the each language we've provided an option to treat the instrumentation safety rules in a specific way.

 

The options are:

 

Automatic instructionStep Performance Validator will choose the appropriate settings based on the detected computer language (using file extensions to identify the language)

 

C, C++, Delphi, one return instructionStep Performance Validator will instrument assuming all lines are C, C++ or Delphi, allowing only one return from a function. Overlapped functions are not allowed.

 

C, C++, Delphi, multiple returns instructionStep Performance Validator will instrument assuming all lines are C, C++ or Delphi, allowing multiple returns from a function. Overlapped functions are not allowed.

 

Fortran instructionStep Performance Validator will instrument assuming all files are Fortran. This allows for multiple entry points and multiple exit points from a function. Overlapped functions are allowed.

 

The default behaviour is Automatic.

 

 

x64 Exception Handling

 

x64 Exception handling is table based, which can cause problem with instrumentation. We provide options to turn instrumentation off in certain circumstances.

 

x64 exception handlers instructionStep do not hook x64 functions that contain an exception handler.

 

x64 functions throwing exceptions instructionStep do not hook x64 functions that throw exceptions.

 

 

Reset All - Resets all global settings, not just those on the current page.

 

 

Reset - Resets the settings on the current page.