Run QEMU with -s switch to enable its GDB stub. The default port number is 1234. If desired, the -p command line switch can be used to change it. The -S command line switch causes the execution to be suspended at startup. For example:

 qemu.exe -s -S -L . -m 128 -hda linux.img -soundhw all -localtime -M pc

For better debugging, make sure to set the following options in GDB Debugger options:

 Software breakpoints at EIP+1: disabled
 Use CS:IP in real mode: enabled (when debugging 16-bit (real-mode) code)

In other aspects debugging with QEMU is the same as debugging for other targets.

Back to Remote GDB Debugger

Make sure the following line is present in the .cfg file for your target:

 gdb_port 3333

Edit the port number if necessary. Specify that port in the process options and use the Debugger, Attach command.

Tips: Use the GDB command line to send commands directly to OpenOCD interpreter. Back to Remote GDB Debugger

Remote GDB Debugger module allows for debugging code using the GDB remote serial protocol. For this, the debuggee must contain a so-called "GDB stub" that controls the execution and handles the remote protocol commands. There are many implementations of such stubs available with different capabilities. The module has been tested with the following GDB stubs: gdbserver: Windows (Cygwin), Linux (ARM, MIPS, PowerPC) VMWare: x86 (16/32 bit) QEMU: x86 (16/32 bit), ARM, MIPS, PowerPC OpenOCD: ARM It is quite possible that the module will work with other stubs. Note that only x86, ARM, MIPS and PowerPC processors are supported at the moment.

Some GDB stubs support so-called "monitor" commands. For example, VMWare stub can return extra info about system registers. Use the command line at the bottom of the main IDA window to send such commands. The output will be displayed in the message window. Hint: most stubs have a "help" command (if they support any commands at all).

The module also makes the following function available from IDC: string send_dbg_command(string command);

 NOTE

When using instant debugging, you will need to tell IDA on which CPU the target is running. This is done in the Remote GDB Debugger options dialog, available via "Debugger specific options" button in the Process options dialog shown when you choose Remote GDB Debugger from the Run or Attach menu.

 NOTE

Many GDB stubs do not report the address that triggered a hardware breakpoint. In this case, IDA will report a memory breakpoint hit as a generic TRAP signal. Examine the previous instruction to see if it referenced a memory location with breakpoint. When continuing from such a breakpoint, choose not to pass the signal to the program.

 NOTE

IDA can be used together with a J-Link debug probe from SEGGER Microcontroller GmbH:

https://segger.com/jlink-debug-probes.html

See also

• Remote GDB Debugger options

• Debugger submenu.

VMWare Workstation 6.5 is recommended for debugging, though earlier versions may work too. Only 32-bit debugging is supported.

In order to enable debugging with GDB protocol, add the following lines to the .vmx file of the virtual machine:

   debugStub.listen.guest32 = "TRUE"
   debugStub.hideBreakpoints= "TRUE"

To debug the VM startup, use:

   monitor.debugOnStartGuest32 = "TRUE"

Please note that the execution will start in the BIOS.

To accept connections from remote computers, the following line must be specified:

   debugStub.listen.guest32.remote = "TRUE"

VMWare Workstation will listen on port 8832.

Tips:

Since the GDB server does not report the memory layout, it must be specified manually. For example, to debug BIOS startup code, create a 16-bit segment from F0000 to 10000 with base F000.

Use the GDB command line to get extra info about the registers. For example, use "r cr0" to see current value of the cr0 register or "r cs" to see the base, limit and other attributes of the CS selector in protected mode.

Back to Remote GDB Debugger

Using the "Run external program" option it is easy to debug small ARM, MIPS or PowePC code snippets directly from inside IDA.

1) Download and install QEMU. Win32 builds can be downloaded from http://homepage3.nifty.com/takeda-toshiya/qemu/.

2) Edit cfg\gdb_arch.cfg file and change the "set QEMUPATH" line to point to the install directory of QEMU.

3) In Remote GDB Debugger options (Debugger|Debugger options, Set specific options), enable "Run a program before debugging".

4) Click "Choose a configuration" and choose a predefined configuration. Choose "for snippets", if mentioned.

5) If necessary, edit the command line or memory map.

6) Click OK, OK to confirm and close the options dialog.

7) In Debugger|Process options make sure that Hostname is set to "localhost" and port is non-zero.

8) Select the code range to emulate or at least the first instruction. Alternatively, you can rename the starting address "ENTRY" and end address as "EXIT".

9) Choose Debugger|Run or press F9.

IDA will write the database into an ELF file (if %e was specified), start QEMU with the specified command line and connect to its GDB stub. It will set the SP and PC values so that the code can be stepped through.

NOTE

While it can be very useful, QEMU emulation has certain limitations:

1) the memory map is usually fixed at compile time. So if your program addresses intersect some of the system regions as specified by the memory map, IDA will refuse to start debugging. In that case, you can either rebase the program so that it fits into RAM regions or check other QEMU board configurations for a compatible memory layout.

2) the emulation starts at the system (kernel) level when there is no OS loaded. That means that system calls and imported functions will not work.

3) the hardware access will only work to the extent emulated by QEMU. If the code you are emulating does not match the chosen board configuration of QEMU, the code accessing the hardware most likely will not work properly, if at all.

See also

• External programs and GDB Debugger

• Remote GDB Debugger

gdbserver is a GDB stub implemented as a separate program. It runs a program to be debugged or attaches to a process and then waits for commands. The remote GDB debugger module has been tested with gdbserver available with Cygwin and Linux.

To debug a specific program from the start, run the following command:

    gdbserver localhost:23946 <program>

and then choose Debugger,Attach,<process running on target> in IDA.

To debug a running process:

    gdbserver --multi localhost:23947

then choose Debugger,Attach,<enter PID to attach> in IDA and enter the PID of the process to attach to.

Another method of debugging a running process is:

    gdbserver localhost:23947 --attach <PID>

then choose Debugger,Attach,<process running on target> in IDA.

To start a program from inside IDA, first launch the debugger server:

    gdbserver --multi localhost:23947

Then use Debugger,Start process or Debugger,Run in IDA.

 NOTE

The --multi option is only available in GDB 6.8 or higher.

Back to Remote GDB Debugger

The "Run a program before debugging" option in Remote GDB Debugger options allows to automatically run a program (such as a debugging server) when starting a debugging session. If you enable it, the following options become available:

Command line

        Command line of the program to run. The following special symbols can be used:

%i: input file name from the Process options dialog %p: port number from the Process options dialog %e: file name of a temporary ELF file created from the database contents Initial SP

        IDA will set the SP (or a similar register) after connecting to the server

Choose a configuration

        Load one of the pre-defined configurations (command line, memory map and SP value)
        described in the gdb_arch.cfg file.

Memory map

        Edit the memory map for the external server. It will be used during debugging.

One use of these options is to debug small code snippets using the QEMU emulator.

See also

• Remote GDB Debugger options

• Debugger submenu.

Max packet size

        Maximum packet size supported by the GDB stub (in bytes).
        Some stubs can crash on big packets, e.g. memory reads. IDA
        will try to split such requests in smaller chunks so that
        replies should fit in this size. You can enter -1 to
        autodetect (in this case IDA will use the size of the
        "g" packet reply as the max packet size).

Timeout

        Default timeout in milliseconds for remote GDB stub responses.
        Some targets can be slow to respond, so increase this value
        when having problems, e.g. with disappearing memory bytes.

Run a program before starting debugging Check to enable external program options. Processor This option is only visible when starting debugger without a database. Use it to specify on which CPU the target is running. For some processors you can also specify the endianness. Software breakpoints at EIP+1

        Most GDB stubs for x86 report software breakpoint hits with EIP one byte after
        the breakpoint address. However, some emulators report the actual breakpoint
        address. This option allows IDA to recognize such situations.
        Recommendations: uncheck for QEMU, check for others.

Use CS:IP in real mode

        When debugging real-mode (16-bit) code, the stub can send either
        just 16 bits of IP register or the full EIP (CS<<4 + IP).
        Enable this option in the former case.
        Recommendations: check for QEMU, uncheck for others.

See also

• Instant debugger

• Remote GDB Debugger