You can collect and analyze data for a program compiled with almost any compiler option, but some choices affect what you can collect or what you can see in Performance Analyzer. The issues to consider when you compile and link your program are described in the following subsections.
To see source code in annotated Source and Disassembly views, and source lines in the Lines view, you must compile the source files of interest with the -g compiler option (-g0 for C++ to enable front-end inlining) to generate debug symbol information. The format of the debug symbol information is DWARF2. specified by -xdebugformat=dwarf . This the default.
Executables and libraries built with DWARF format debugging symbols automatically include a copy of each constituent object file’s debugging symbols. Executables and libraries built with stabs format debugging symbols also include a copy of each constituent object file’s debugging symbols if they are linked with the –xs option, which leaves stabs symbols in the various object files as well as the executable. The inclusion of this information is particularly useful if you need to move or remove the object files. With all of the debugging symbols in the executables and libraries themselves, moving the experiment and the program-related files to a new location is easier.
Programs can be compiled with the Oracle Developer Studio compilers or GNU compilers. However, GNU compilers cannot support some features such as reconstructed call stacks with OpenMP.
Compiling with -g does not change optimization, except for tail call optimization at the O2 and O3 optimization levels in Oracle Developer Studio compilers.
Source level information for Java code is supported. The location of Java sources, unlike that for native languages, is not recorded in the experiments. You might need to use path mapping or set the search path to point to your source. See How the Tools Find Source Code for more information.
Dataspace profiling attributes memory access to data structure elements. To enable dataspace profiling, you must compile C, C++, and Fortran executables with the Oracle Developer Studio compilers and the -xhwcprof option. If you do not compile with this option, the DataObjects and DataLayout views do not show data for the binaries.
Memoryspace profiling enables you to see which memory addresses are costing the most performance. No special compiler options are necessary to prepare a program for memoryspace profiling, but the feature is available only on SPARC platforms running Oracle Solaris 10 1/13, and on Intel platforms running Oracle Solaris 11.2. See Dataspace Profiling and Memoryspace Profiling for more information.
For some types of performance data such as heap tracing and I/O tracing, data collection relies on a dynamically linked libc. This functionality is lost when you link statically, so you should not use options such as -dn and -Bstatic to control libcwith Oracle Developer Studio compilers.
If you try to collect data for a program that is entirely statically linked, the Collector prints an error message and does not collect data. The error occurs because the collector library, among others, is dynamically loaded when you run the Collector.
Do not statically link any of the system libraries or the Collector library, libcollector.so.
Normally the collect command causes data to be collected for all shared objects in the address space of the target, regardless of whether they are on the initial library list or are explicitly loaded with dlopen(). However, under some circumstances some shared objects are not profiled:
When the target program is invoked with lazy loading. In such cases, the library is not loaded at start-up time, and is not loaded by explicitly calling dlopen(), so shared object might not be not included in the experiment, and all PCs from it are mapped to the <Unknown> function. The workaround is to set the LD_BIND_NOW environment variable, which forces the library to be loaded at start-up time.
When the executable was built with the –B direct option. In this case, the object is dynamically loaded by a call specifically to the dynamic linker entry point of dlopen(), and the libcollector interposition is bypassed. The shared object name might not be included in the experiment, and all PCs from it are mapped to the <Unknown>() function. The workaround is to not use the –B direct option. If the program terminates normally, such shared objects are detected and recorded.
If you compile your program with optimization turned on at some level, the compiler can rearrange the order of execution so that it does not strictly follow the sequence of lines in your program. Performance Analyzer can analyze experiments collected on optimized code, but the data it presents at the disassembly level is often difficult to relate to the original source code lines. In addition, the call sequence can appear to be different from what you expect if the compiler performs tail-call optimizations. See Tail-Call Optimization for more information.
No special action is required for compiling Java programs with the javac command.