H-Series Application Migration Guide (H06.03+)

Reporting Compiler Optimization Problems
H-Series Application Migration Guide—429855-006
C-3
Additional Information Needed for Runtime Abort
Additional Information Needed for Runtime Abort
When reporting a runtime abort error, you should provide the same information as for
an incorrect results error. If you cannot provide that information, the problem can
sometimes be isolated by examining the compiled object file that contains the error, the
dump file produced by the object file, and the preprocessed source file in which the
error occurred. Tips for providing this “alternative” information are described next.
Tips for Providing Alternative Debugging Information
If you are unable to provide the working environment for reproducing the failure, you
can provide certain low-level information that can be used to understand the failure
without the need to build and run the program. Using one of the native debugging
tools, examine the dump for the following information:
•
Save the stacktrace. (Use the Inspect backtrace (bt) command and place the
output in a text file.)
•
Identify the point of failure by recording the file name, function name, and line
number (if available) in the program where the failure occurs.
•
Working backwards from the point of failure, obtain the values of variables and
registers that reach and affect the point of failure.
•
Obtain the values of the input variables (usually indicated in the stacktrace
generated by the bt command).
•
Use this variable and register state at the point of failure to verify that your program
could never reach this particular failure state as a result of a programming error.
•
It might also be helpful to create an optimize file (described next) and attempting to
isolate the routine where the failure occurred by lowering the optimization level for
each routine in the stacktrace, one at a time, beginning with the topmost routine.
(However, the point of failure could be in a procedure that has finished executing
and is no longer in the stacktrace.)
Note. These values are not readily available when the code is optimized. To obtain these values,
proceed as in this example:
Suppose your stacktrace shows CALLEE at the top and CALLER at the bottom. To determine what
values CALLER called CALLEE with:
•
Change frames to CALLER.
•
Identify the alloc instruction at or near the beginning of the function (There might be more than
one, so trace backwards from the call to find it.) Use the alloc call to obtain the parameter
values. For example, alloc r32=ar.pfs,4,3,0 indicates that the first parameter passed to
CALLEE is in register r(32+3), or register 35. The next parameter is in register 36, and so on.