Document Number: 322072-004US
This package contains the Intel(R) Application Debugger 2.0 for Intel(R) Atom(TM) processor.
It provides Linux* hosted cross-debug solutions for Linux* software developers to debug C and C++ applications via a remote TCP-IP debug handler kernel module on Mobile Internet Device development platforms. The debugger through a powerful graphical user interface (GUI) provides full process and thread aware debug capabilities through a powerful OS awareness plug-in. Additionally it provides convenient and in-depth access to underlying hardware properties that make it an ideal assistant for application debugging in an embedded custom design environment. The rich offering for application developers is completed through a set of features like
The developer thus gains the extra level of visibility into the system they develop on they want. This minimizes the time it takes to isolate and correct application level problems by understanding the system environment the application runs on as well as the application itself.
Information on Intel Software Development Products is available at http://www.intel.com/software/products/.
This product includes software developed at:
The Apache Software Foundation (http://www.apache.org/).
Portions of this software were originally based on the following:
- software copyright (c) 1999, IBM Corporation., http://www.ibm.com.
- software copyright (c) 1999, Sun Microsystems., http://www.sun.com.
- the W3C consortium (http://www.w3c.org) ,
- the SAX project (http://www.saxproject.org)
- voluntary contributions made by Paul Eng on behalf of the
Apache Software Foundation that were originally developed at iClick, Inc.,
software copyright (c) 1999.
This product includes updcrc macro,
Satchell Evaluations and Chuck Forsberg.
Copyright (C) 1986 Stephen Satchell.
This product includes software developed by the MX4J project
(http://mx4j.sourceforge.net).
This product includes ICU 1.8.1 and later.
Copyright (c) 1995-2006 International Business Machines Corporation and others.
Portions copyright (c) 1997-2008 Cypress Semiconductor Corporation.
All rights reserved.
This product includes XORP.
Copyright (c) 2001-2004 International Computer Science Institute
This product includes software from the book
"Linux Device Drivers" by Alessandro Rubini and Jonathan Corbet,
published by O'Reilly & Associates.
This product includes hashtab.c.
Bob Jenkins, 1996.
-------------------------------------------
ERROR: Problem encountered executing chklic utility located here:
/home/qa/l_MID_DBG_p_2.1.xxx/data/chklic.32
The chklic program /home/qa/l_MID_DBG_p_2.1.xxx/data/chklic.32 requires these libraries:
linux-gate.so.1 =>
libpthread.so.0 => /lib/libpthread.so.0
libm.so.6 => /lib/libm.so.6
libstdc++.so.5 => not found
libgcc_s.so.1 => /lib/libgcc_s.so.1
libc.so.6 => /lib/libc.so.6
libdl.so.2 => /lib/libdl.so.2
/lib/ld-linux.so.2
You need to install libstdc++5 library to continue the installation.
It requires superuser or "root" privileges.
Exiting installation program.
-------------------------------------------
One of the following environments:
Extract the downloaded l_MID_DBG_p_2.1.xxx.tar.gz file into
a temporary directory.
Run the install.sh script following all instructions. Please see the Installation Guide for more detailed instructions on the installation process.
The documentation for this release is installed in the directory (default) /opt/intel/atom/documentation/idb/ and includes these release notes Release_Notes_IDB.htm, an installation guide Install_Guide_IDB.htm, a getting started guide Getting_Started.html , and a documentation index. In addition, the Intel(R) Application Debugger for Intel(R) Atom(TM) processor includes online help provided in form of the document titled "Intel(R) Debugger Online Help", which is available from the Help menu of the graphical user interface (GUI).
Support for
has been added to this release.
Enables viewing of execution history with OS thread awareness and thus while excluding system events enhances understanding of the flow of an executed program allowing the analysis of the execution path and to find errors and identify the root cause for exceptions. Please see the installation guide Install_Guide.htm for details on how to apply the necessary Linux* kernel patch for this feature.
Create a batch file based on a rich set of powerful debugging script language commands and execute it in non-interactive mode. Results can be logged and analyzed afterwards.
The user can store basic debug session settings such as connection information, substitution paths, environment variables, loaded debuggee and load arguments, breakpoints and watchpoints. These settings can then be retrieved by loading the previously stored session settings file. This makes it easy to commence a debug session where the user may have left off earlier.
This release features more GDB compatibility features in it's command language interface. Included are the following features:
The debugger will read .gdb_history by default. You can also use the following commands to control the behavior of command history:
If neither of these choices are used, the default value is 256. s
info var[iables] [<string>|REGEXP]
<string> is a simple search string; REGEXP is a regular expression. The resulting list is the list of global and static variables in the debuggee that match <string> or REGEXP.
info fu[nctions] [<string>|REGEXP]
<string> is a simple search string; REGEXP is a regular expression. The resulting list is the list of global and static functions in the debuggee that match <string> or REGEXP.
info ty[pes] [<string>|REGEXP]
<string> is a simple search string; REGEXP is a regular expression. The resulting list is the list of types used in the debuggee that matches <string> or REGEXP.
Completion of commands, filenames, and variables is supported. Simply start typing a command, filename or variable and press the tab key. If there is more than one alternative, the debugger sounds a bell; pressing tab again causes the debugger to list the alternatives.
Using single and double quotes influences the set of possible alternatives. Single quotes can be used to fill in C++ names, which contains special symbols (":", "<", ">", "(", etc.). Double quotas tell the debugger to look for alternatives among file names only.
The debugger doesn't automatically detect cases where quotes are needed (as GDB does).
The debugger
now supports user defined commands. These commands support if, while,
loop_break and loop_continue in their bodies. User-defined commands
can have up to 10 arguments separated by whitespace. Argument names are $arg0,
$arg1, $arg2,...,
$arg9. The number
of arguments is held in $argc.
The debugger supports the following commands to control user-defined commands:
(idb) set max-user-call-depth <depth>
(idb) show
max-user-call-depth The debugger doesn't yet support the document, help user-defined, dont-repeat commands or user-defined hooks.
If the user tries to set a breakpoint which cannot be resolved to as specific location, the debugger asks the user whether to create a special breakpoint, called a pending breakpoint. This breakpoint will be evaluated when shared libraries are loaded and if they can be resolved, that are transformed into a regular breakpoint (where the debugger can stop). The debugger supports specific commands for managing the pending breakpoint support:
(idb)set breakpoint pending auto
This is the default value. If the debugger cannot resolve breakpoint location, the user is asked whether to create a pending breakpoint.
(idb)
set breakpoint pending on
Always set pending breakpoints on unresolved locations.
(idb) set breakpoint pending off
Never set pending breakpoint on unresolved locations.
(idb) show breakpoint pending
Show the behavior of the pending breakpoint support.
Normal breakpoint operations are valid for pending breakpoints. Pending breakpoints can be enabled, disabled and deleted. A user condition can be assigned to pending breakpoint and it will be promoted to the breakpoint when the location is resolved.
The Intel(R) C++ Application Debugger for Linux* OS Supporting Mobil Internet Devices now supports hardware watchpoints using dedicated target processor registers additionally to software watchpoints.
The syntax for the hardware watchpoint support is
(idb) idb hawatch <address>:<size>
(idb) idb hwatch <address>:<size>
hawatch sets a hardware watchpoint at address with specified size that gets triggered by any access.
hwatch sets a hardware watchpoint at address with specified size that gets triggered by write accesses only.
The optional size parameter defines the range of memory
that gets watched. Only 1,2,4 are currently valid sizes.
This info also accessible via help hawatch or
help hwatch.
The debugger's watchpoint dialog also provides GUI support for this command and the debugger's symbol selector can be used to select a variable for the hardware watchpoint address.
Since hardware watchpints require explicit addresses,
please make sure that you specify a memory address if you add the watchpoint
location in this dialog manually, either by typing in an address or by
specifying &<variable name>.
Typically when developing for the Intel(R) Atom(TM) processer the target system environment and a host system environment differ. Different system libraries like "libgcc_s.so.1", "libc.so.x" etc. at the host side and target side may have a significant performance impact when debugging remotely. All debug-information of those libraries will be read by the application debugger via the network lin, which can take a considerable amount of time. The workaround to adddress this issue is to use one of the following two approaches
When the host environment is not in sync with the target environment, the debugger will download needed files from the target. As this process can be time-consuming, a warning message is printed to the debugger's console window to indicate which file is inconsistent. This warning message will be issued every time the data for the out-of-sync remote file is being loaded, causing a possibly considerable amount of diagnostic messages in the console window.
Therefore for shared object debugging it is strongly encouraged to copy the target system (shared) libraries to a location on the host and using the "Shared Library Settings" in the application debugger to replace the (shared) library path in the debuggee (finding the path out by using tool like "readelf") with the location on the host.
Each time when the application being debugged is continued, the trace buffer is cleared to record new trace data. Depending on how much time has passed between the continuation and the next stop, there might be any amount (between zero and n) branch trace entries recorded. Depending on the amount of trace data recorded, the trace window can be empty, contain disassembly from the last taken branch or have a longer history of execution. Especially run-control commands with short run-stop cycles, i.e. STEP, may yield short or no trace output. To benefit most from trace, enable it at the beginning of your application, then run into the unwanted condition being debugged, this can be a breakpoint at a location that is never expected to be hit or a system exception/signal.
When setting a breakpoint in a shared library while the debuggee is not running, the pending breakpoint for the shared library may be set at an incorrect memory address.
If you intend to set a breakpoint in a shared library it is therefore recommended to load the debuggee first.
(idb) file test_debuggee
(idb) b
main
(idb) run
(idb) b shared_library.c:333 <- create
shared library BP here
After rerun you should remove the BPs on the shared library again and create new ones.
$sessiondir to
provide a relative path for the file to save the session information is not
supported. The default is $PWD/workspace/sessions/ where $PWD is the working directory where the GUI was started. The path info can be retrieved with the command
print $sessiondir at the IDB command line. It is currently recommended to
provide absolute paths to store your session information instead of using the
$sessiondir variable.
When performing a symbol search in the Symbol Selector Dialog it can happen that both the symbol definition and the symbol declaration are being found creating the false impression of possible duplicate symbols in the user code. This is due to a scope resolution issue in the search functionality. Both items displayed point to the same symbol identifier in the debugger, thus no matter which of the two displayed items is being selected it will be resolved correctly.
If there are duplicate symbols in different link units (e.g. an identical symbol name is used in the main executable as well as a shared object used by that executable), the symbol selector may not be able to distinguish the two and the symbol may not be resolved correctly pointing to either of the symbols.
The symbol selector result tree for the valid link units of an application will display the shared library filename without path information. If there are two shared libraries with the same filename, there will be two subtree entries for these libraries, but there will be no unqiue identifier distinguishing the two.
If the simultaneous search for functions and variables finds entries for both function names and variable names that fit the search pattern the result tree display may have errors.
A search on function local variables will only display those that are in the current frame.
Variables and subclasses inside overloaded functions are not actively supported. Thus even if these symbols are found the debugger may not be able to resolve their value.
Some compilers may not produce symbol info that allows for correct symbol resolution inside a namespace. resolves
The "Open Executable" and "Rerun with Arguments" dialogs permit the user to set environment variables before launching the debuggee from within the debugger. If an environment variable is being set in the "Open Executable" dialog this setting is currently not inherited for the rerun of the executable, but needs to be set explicitly in the "Rerun with Arguments" dialog as well.
To successfully debug shared libraries it is necessary to define a rule that maps to the shared library object on the host environment. The basic command line syntax for this purpose is
(idb) set solib-path-substitute <dir-path>
<replacement-dir-path>
This can also be done using the debugger's graphical user interface. In the "Options" pulldown menu under "Shared Library Settings" you could select "Shared Library Path Substitutions" and enter the two paths to be mapped.
Using the GUI as well as the command line you can also remove shared object path substitution rules
(idb) unset
solib-path-substitute [ <dir-path> ]
or display them
(idb) show solib-path-substitute
Below is a brief description of an example how to apply this functionality specifically when working with a Moblin Image Creator based Chroot / Buildroot environment:
Let us assume we have the following environment setup using the Moblin Image Creator
$HOME: /home/mid_user
Project: mid_project
Target: mid_cb_full
Application directory (inside chroot environment): root/my_app
The application executable may be named sample_app and the shared
library used may be named sample_lib.so for the sake of our example.
Under the assumption that we created a LiveRW image, after building the
application we should then find that the image on the USB drive contains the
directory /root/my_app/along with the application.
The application should then be launched and loaded into the debugger using the "Load" button to open the "Open Executable" dialog. The settings used in this "Open Executable" dialog are
Local Executable File=/home/mid_user/mid_project/targets/mid_cb_full/fs/root/my_app/sample_app
Remote Executable File=/root/my_app/sample_app Additionally you will want to define a rule that allows the debugger to find the shared library associated with the debuggee application.
The rule would intuitively be set as follows
idb set solib-path-subst / /home/mid_user/mid_project/targets/mid_cb_full/fs/
However, the IDBserver communication handler on the MID
target device
reads from the file /proc/<pid>/maps, that there is a shared
library in /squashmnt/root/my_app/sample_lib.so. To accommodate
this path as found by IDBserver the correct shared library mapping rule
for an application that is part of the LiveRW image instead needs to be
idb set solib-path-subst / /squashmnt/home/mid_user/mid_project/targets/mid_cb_full/fs/If the application is copied onto the target device separately after the creation of the target image, the shared library image mapping rule needs to be
idb set solib-path-subst / /persistmnt/home/mid_user/mid_project/targets/mid_cb_full/fs/
instead. Please note that the only difference is the /persistmnt versus /squashmnt option.
When trying to refresh the disassembly via selecting Reload in the mouse context menu of the disassembly window, no disassembly reload will be done. The workaround is to select the Recapture button to do a target status recapture before reloading the disassembly.
It is currently not possible to change FPU register values using the Change Register Dialog
Callstack Information may be Incorrect
The function callstack displayed in the callstack window may be corrupted and provide false call information.
If you are connecting to the target device and opening an evaluation window in the debugger before attaching to the debuggee process. If you are then adding an evaluation of a debuggee process symbol to the evaluation window whether the process is attached or not, the value of this variable will not be updated in the evaluation window. It won't be updated until the debuggee process is relaunched.
Copying a file path from a secure shell into a debugger dialog using Ctrl-C and Ctrl-V key combinations or the usual Linux* text copy approach may not work.
The Intel(R) Application Debugger only supports debugging of executables whose debug information is in Dwarf format, and does not support the Stabs debug format. With GCC versions earlier than 3.x the option -g might generate DWARF-1. If so, use the -gdwarf-2 flag on the compile command to have gcc and g++ generate Dwarf output. The Intel compilers (icc) produce Dwarf debug format.
For example:
Use the -g option with the Intel C++ Compiler:
%icc -g hello.c
...
%icpc -g hello.cpp
With the GNU* Compiler Collection (GCC, versions earlier than 3.x), use the
-gdwarf-2 option:
%gcc -gdwarf-2 hello.c
...
%g++ -gdwarf-2 hello.c
Parallel debug support has been removed from the debugger for this release. Disabling of parallel features however is temporary only until an extension to the IDB Server is applied.
When debugging an application remotely, the debugger is on one machine
(the "client") and the target is on another (the "server"). The debugger
needs a client-side copy of the target executable from which it can read the
debug information as it has only limited access to files on the server.
If you wish to debug shared libraries used by the target, you must also have
client-side copies of those shared libraries. To tell the debugger where
those copies are, set the environment variable LOCAL_COPY_OF_REMOTE_LIBS to
the directory where you have put those copies.
Example:
$ mkdir /usr/users/me/copies
$ cp libone.so /usr/users/me/copies
$ cp libtwo.so /usr/users/me/copies
$ setenv LOCAL_COPY_OF_REMOTE_LIBS /usr/users/me/copies
$ idb -idb_remote ...
In this example, the two shared libraries of interest are copied to the
directory "copies". The environment variable is set to that directory.
When the remote target executes code in one of those shared libraries the
debugger will be able to read debug information about that library from the
copy in that directory and provide symbolic debugging.
For general support information please visit Intel's Software Developer Support homepage.
To submit issues related to this product please visit the Intel Premier Support webpage and submit issues under the product Intel(R)Embedded SW Dev Tools Atom.
For information on how to register for and purchase support for the Intel(R) Embedded Software Development Tool Suite for Intel(R) Atom(TM) processor please visit the Intel(R) Software Development Products webpage.
Additional support for this product is available at the Intel(R) Software Development Tool Suites for Intel(R) Atom(TM) processor forum which is a sub-forum of the Intel(R) Software Network Community Forums for issue discussion and community support.
Intel processor numbers are not a measure of performance. processor numbers differentiate features within each processor family, not across different processor families. See http://www.intel.com/products/processor_number for details.
BunnyPeople, Celeron, Celeron Inside, Centrino, Centrino Atom, Centrino Atom Inside, Centrino Inside, Centrino logo, Core Inside, FlashFile, i960, InstantIP, Intel, Intel logo, Intel386, Intel486, IntelDX2, IntelDX4, IntelSX2, Intel Atom, Intel Atom Inside, Intel Core, Intel Inside, Intel Inside logo, Intel. Leap ahead., Intel. Leap ahead. logo, Intel NetBurst, Intel NetMerge, Intel NetStructure, Intel SingleDriver, Intel SpeedStep, Intel StrataFlash, Intel Viiv, Intel vPro, Intel XScale, Itanium, Itanium Inside, MCS, MMX, Oplus, OverDrive, PDCharm, Pentium, Pentium Inside, skoool, Sound Mark, The Journey Inside, Viiv Inside, vPro Inside, VTune, Xeon, and Xeon Inside are trademarks of Intel Corporation in the U.S. and other countries.
* Other names and brands may be claimed as the property of others.
Copyright 2007-2009, Intel Corporation. All rights reserved.