idb_release_notes.html

里面有详细计算程序设计手册和原码分析 fortran90-and-computational-science

	     	<p>
		This command displays the information of the OpenMP
		teams that are specified, or that of all the teams if none is
		specified. E.g.:
		</p>
		<p><pre><code>
	(idb) show team 6917529027641120768
	OpenMP Team:  6917529027641120768
	Parent Team:  6917529027641117440
	Created At:   "/projects/OpenMP/src/c_omp.c":main:58:98
	Team members
	  [0] Thread 1, is master of team 6917529027641153024
	  [1] Thread 3, is master of team 6917529027641184768
		</code></pre></p>
	  </li>
	  <li><b><code>show thread [<i>thread id, ...</i>]</code></b>
		<p>
		This command displays the information of the threads
		that are specified, or that of all the threads if none is
		specified. E.g.:
		</p>
		<p><pre><code>
	(idb) show thread 3
	   3     openmp thread 2305843009228110032 (LWP 13080)
	         stopped at 0x2000000000866922
	         OpenMP team memberships: (6917529027641184768,0), (6917529027641120768,1)
		</code></pre></p>
		<p>
		The ID in front of LWP is the thread ID assigned by
		the pthread library.
		<br>
		The first component of a pair in the OpenMP team memberships 
		is a team ID, and the second compoenent is the OpenMP thread 
		ID in that team. These pairs are listed from the innermost
		team membership to the outer ones. 
		</p>
	  </li>
	</ol>
	<p>
	The first three commands are also available in GDB mode.
	To inspect a thread in GDB mode, use the "<code>info thread</code>"
	command.
	</p>
	<p>
	Another feature that is available when debugging an OpenMP
	application is <i>stack stitching</i>. Here is a typical 
	backtrace of an OpenMP thread:
	<p>
	<pre><code>
	(idb) where thread 1
	Stack trace for thread 1
	>0 0x0000000000400cb8 in thread_func(param=0) "c_omp.c":14
	#1 0x0000000000400dc4 in main() "c_omp.c":23
	<b>#2 0x0000002a95595d43 in __kmp_invoke_microtask(...) in libguide.so
	#3 0x0000002a9559e572 in __kmpc_invoke_task_func(...) in libguide.so
	#4 0x0000002a9559e75d in __kmp_internal_fork(...) in libguide.so
	#5 0x0000002a955982fa in __kmp_fork_call(...) in libguide.so
	#6 0x0000002a955a09f2 in __kmpc_fork_call(...) in libguide.so</b>
	#7 0x0000000000400d94 in main() "c_omp.c":21
	#8 0x0000003cad01c4ca in __libc_start_main(...) in /lib64/tls/libc-2.3.4.so
	#9 0x0000000000400b40 in _start(...) in c_omp
	</code></pre>
	<p>
	In this backtrace, the frames in boldface correspond to functions
        in the OpenMP runtime library, which most users don't care
 	about and only make the backtrace less comprehensible. 
	Stack stitching removes those OpenMP runtime frames and put
        the remaining frames back together into a backtrace that
	maps cleanly to the user's source code:
	<pre><code>
	(idb) where thread 1
	Stack trace for thread 1
	>0 0x0000000000400cb8 in thread_func(param=0) "c_omp.c":14
	#1 0x0000000000400dc4 in main() "c_omp.c":23
	#2 0x0000000000400d94 in main() "c_omp.c":21
	#3 0x0000003cad01c4ca in __libc_start_main(...) in /lib64/tls/libc-2.3.4.so
	#4 0x0000000000400b40 in _start(...) in c_omp
	</code></pre>
 	<p>
	When an OpenMP thread is a non-master member thread of a team,
	the stitched backtrace would show you the backtrace of 
	the master thread starting with the frame that spawns the team:
	<p>
	<pre><code>
	(idb) where
	>0  0x08048cf2 in foo() "src/c_stack_stitching.c":9
	#1  0x08049162 in main() "src/c_stack_stitching.c":35
	======== Frames from Team 134587904 master Thread 3 ========
	#7  0x08049139 in main() "src/c_stack_stitching.c":33
	======== Frames from Team 134548736 master Thread 1 ========
	#7  0x08048fdc in main() "src/c_stack_stitching.c":22
	#8  0x08048ef4 in main() "src/c_stack_stitching.c":18
	#9  0x08048e0c in main() "src/c_stack_stitching.c":15
	#10 0xb7380748 in __libc_start_main(...) in /lib/tls/libc-2.3.2.so
	#11 0x08048b01 in _start(...) in c_stack_stitching
	</code></pre>
	<p>
	When <code>$threadlevel</code> is set to <code>"openmp"</code>, 
	the value of the debugger variable <code>$openmpstackstitching</code> 
	determines whether stack stitching is enabled: If its value is 0, 
	stack stitching is disabled; otherwise, it is enabled. 
	<code>$openmpstackstitching</code> is set to <code>1</code> by 
	default. When <code>$threadlevel</code> is set to 
	<code>"native"</code>, stack stitching is disabled, 
	regardless of the value of <code>$openmpstackstitching</code>.
	<p>
	See <a href="#_OpenMP_issues">
        Known Limitations</a> for a list of issues with OpenMP support.
	</p>
      </p>
      

      <h3> <a name=EclipseStartup_></a>
       Eclipse* Support</h3>
      <p>
        The Intel C++ Compiler for Linux* includes a debugger integration 
        with Eclipse* and the C/C++ Development Tools* (CDT).  
        This functionality is part of the debugger installation for 
        IA-32 and Itanium&reg; processors.
      </p><p>
        Eclipse is an open source software development project dedicated 
        to providing a robust, full-featured, commercial-quality, 
        industry platform for the development of highly integrated tools. 
        It is an extensible, open source integrated development environment 
        (IDE).
      </p><p>
        The CDT (C/C++ Development Tools) project is dedicated to providing 
        a fully functional C/C++ IDE for the Eclipse platform. CDT is layered 
        on Eclipse and provides a C/C++ development environment perspective.
      </p><p>
        The Intel Debugger integration with the Eclipse/CDT IDE lets you 
        debug your C/C++ projects in a visual, interactive environment. 
      </p><p>
      Intel C++ Compiler 9.1 includes integration for 
            <ul>
            <li>Eclipse* 3.1 and 3.1.1
            <li>C/C++ Development Tools* (CDT) 3.0 &amp; 3.0.1
            </ul>
       </p><p>
      Intel C++ Compiler 10.0 includes integration for 
            <ul>
            <li>Eclipse* 3.2.1 
            <li>C/C++ Development Tools* (CDT) 3.1.1
            </ul>
       </p><p>
        Full details can be found in the<br>
        <div style="margin-left: 40px;">   
        <h4>Intel&reg; Debugger Manual</h4>
        </div>
	<p>
        which is found in the installation directory where these 
        release notes reside.</p>
        <p>
       <br> See <a href="http://www.eclipse.org">http://www.eclipse.org</a> for Eclipse Support. 
       <br> See <a href="http://www.eclipse.org/cdt">http://www.eclipse.org/cdt</a> for further
           information about CDT. 
        </p> 

      <h3> <a name=CLOMP_>
      Intel&reg; Cluster OpenMP Support</a></h3>
	<p>
      	The debugger is now capable of debugging an Intel&reg; Cluster 
	OpenMP application, bringing all the processes in a cluster
	OpenMP job under the debugger's control, and allowing the user
	to control all the processes in the job conveniently from one 
	debugger.
        </p><p>
        To enable this support, the debugger requires access to
	the shared library <code>libomp_db.so</code>, which by default 
	is in the <code>lib</code> directory in your compiler installation.  
        </p><p>
	Before you start debugging a cluster OpenMP job with the debugger,
	make sure you have the environment variable <code>IDB_HOME</code>
	set to the directory where the debugger is installed.
        </p><p>
	To start a fresh cluster OpenMP job under the debugger's control, do
	the following:
	</p><p>
	<code><pre>
	<strong>% $IDB_HOME/idb -clomp &lt;<i>executable</i>&gt; [<i>arguments to the executable</i>]</strong>
	</pre></code>
	<p>
	To attach to an existing cluster OpenMP job, do this:
	<p>
	<code><pre>
	<strong>% $IDB_HOME/idb -pid &lt;<i>pid</i>&gt -clomp &lt;<i>executable</i>&gt; [<i>arguments to the executable</i>]</strong>	
	</pre></code>
	<p>
	where <i>&lt;pid&gt;</i> can be the process-id of any process in the job.
        <p>	
        This support uses the same debugger network infrastructure
        as the MPI debugging support. When debugging a cluster 
	OpenMP job, the debugger provides a "stop the world" 
	event handling model and an "all processes run"
        process control model. The "stop the world" model stipulates
	that when a process in the job raises an event, such as a
	breakpoint hit, the debugger would stop <i>all</i> the processes
	in the job and issues the user prompt. The "all processes run"
	model stipulates that when the user issues a mover command
	(such as "<code>cont</code>" or "<code>next</code>"), 
	<i>all</i> the processes in the job are resumed. The reason 
	that these models are used is to make debugging a cluster 
	OpenMP job as similar as possible to debugging a regular 
	OpenMP process, which also uses the "stop the world" and 
	"all threads run" (i.e., a single-process version of 
	"all process run") models.
	<p>
	In addition to providing all the commands available in
	MPI debugging, this support provides all the 
	<a href="#OpenMP_Support_"> OpenMP debugging features</a>, 
	except that the command "<code>show openmp thread tree</code>" 
	is not yet implemented.
	<p>
	Note that on Itanium&reg;, this support is available only
	for Linux with kernel version 2.6.9 or newer.
	<p>
	For more information on debugging Intel&reg Cluster OpenMP 
	applications and debugging parallel applications in general, 
	see Chapter 19 of the manual.
    </div>	

    
<h2><a name="Install"></a>Installation Notes</h2>
<div style="margin-left: 40px">
    The following applies when the debugger is packaged with Intel&reg; compiler versions
    8.x or later:<br>
      <br>
      <div style="margin-left: 40px;">
      The environment variable, PATH, can be set to  the location of installed 
      binaries. Debugger configuration scripts are generated during installation. 
      They contain the appropriate values of PATH and MANPATH.
      <br>
      <br>
      The environment can be set up by sourcing the scripts 
      <i>idbvars.sh (.csh)</i>:
      <br>
      <br>
      <code>source &lt;install-dir-path&gt;/bin/idbvars.sh (.csh)</code>
      </div>
</div>

<h2><a name="Limitations"></a>Known Limitations</h2>
    <div style="margin-left: 40px">
    All platforms:
        <div style="margin-left: 40px">
        <a href="#Debugging_Multi-threaded_applications">Debugging multi-threaded
        applications</a><br>
        <a href="#_Debugging_fork">Debugging applications that fork</a><br>
        <a href="#_Debugging_exec">Debugging applications that exec</a><br>
        <a href="#_Snapshots">Snapshots</a><br>
        <a href="#_Debugging_optimized_code">Debugging optimized code</a><br>
        <a href="#_Watchpoints">Watchpoints</a><br>
        <a href="#TLS_">Thread Local Storage</a><br>
        <a href="#_Fortran_modules">Fortran modules</a><br>
        <a href="#_Gui_limitations">GUI</a><br>
        <a href="#MPP_Debugging_Restrictions">MPP Debugging Restrictions</a><br>
        <a href="#Examining_errno">Examining <span style="font-style: italic;">errno</span></a><br>
        <a href="#Compilation_switch_anomolies">Compilation Anomalies</a><br>
        <a href="#_gcc3and4">GCC 3.4 &amp; 4.0</a><br>
        <a href="#_OpenMP_issues">Issues in OpenMP Support</a><br>
        </div>
        
    <p></p>Itanium&reg;:
        <div style="margin-left: 40px">
        <a href="#_Function_Breakpoints">Function Breakpoints</a><br>
        </div>
        
    <p></p>IA-32:
        <div style="margin-left: 40px">
        <a href="#Source_Correlation">Source Correlation</a><br>
        <a href="#_Debugging_functions_in_1">Debugging functions in shared
        libraries</a><br>
        <a href="#Running_on_RedHat_8.0">Running on Red Hat* 8.0, Red Hat* 9.0, or Fedora Core</a><br>
        <a href="#Running_on_FC5">
        Running on Fedora Core 5 &amp; RedHat EL 5.0</a><br>
        </div>
        
    <p></p>Intel&reg; Extended Memory 64 Technology (Intel&reg; 64):
        <div style="margin-left: 40px">
        <a href="#Support_2">Processor support</a>
        </div>

    <h3><a name="Debugging_Multi-threaded_applications"></a>
    Debugging multi-threaded applications</h3>
    <p>
    When debugging multi-threaded applications, probing mutexes and
    condition variables is not yet supported.
    </p>

    <h3><a name="_Debugging_fork"></a>
    Debugging applications that fork</h3>
    <p>
    Debugging the child process of an application that calls fork is not yet 
    supported.
    </p>

    <h3><a name="_Debugging_exec"></a>
    Debugging applications that exec</h3>
    <p>
    The <code>$catch_execs</code> debugger control variable is not supported.
    </p>

    <h3><a name="_Snapshots"></a>Snapshots</h3>
    <p>
    Snapshots are not yet supported as described in the manual.
    </p>

    <h3><a name="_Debugging_optimized_code"></a>Debugging optimized code</h3>
    <p>
    Debugging optimized code is not yet fully supported. The
    debugger may not be able to see some function names, parameters,
    variables, or the contents of the parameters and variables when 
    code is compiled with optimizations turned on. However, the 
    <b>"-debug extended"</b> option is recommended (with <b>-O -g</b>, 
    for example) 
    when compiling to debug optimized code.
    </p>

    <h3><a name="_Watchpoints"></a>Watchpoints</h3>
    <p>
    Watchpoints that are created to detect read access don't trigger
    as documented in the manual. Watchpoints that are created to detect 
    write access don't trigger when a value identical to the value in the 
    variable or memory location has 
    been written. These restrictions are due to a limitation in the Linux 
    operating system
    </p>

    <h3 > <a name="TLS_"></a>
    Thread Local Storage</h3>
    <p>
    Variables in thread local storage are declared in a multi-threaded 
    program with the keyword <b>__thread</b>. The debugger supports 
    manipulations of these variables. However, the debugger may not 
    correctly locate a variable in thread local storage on the Itanium