While nearly all gdb commands are available for all native and cross versions of the debugger, there are some exceptions. This chapter describes things that are only available in certain configurations.
There are three major categories of configurations: native configurations, where the host and target are the same, embedded operating system configurations, which are usually the same for several different processor architectures, and bare embedded processors, which are quite different from each other.
This section describes details specific to particular native configurations.
On HP-UX systems, if you refer to a function or variable name that begins with a dollar sign, gdb searches for a user or system name first, before it searches for a convenience variable.
Many versions of SVR4 provide a facility called /proc that can be used to examine the image of a running process using file-system subroutines. If gdb is configured for an operating system with this facility, the command info proc is available to report on several kinds of information about the process running your program. info proc works only on SVR4 systems that include the procfs code. This includes OSF/1 (Digital Unix), Solaris, Irix, and Unixware, but not HP-UX or gnu/Linux, for example.
Summarize available information about the process.
Report on the address ranges accessible in the program, with information on whether your program may read, write, or execute each range.
djgpp is the port of gnu development tools to MS-DOS and MS-Windows. djgpp programs are 32-bit protected-mode programs that use the DPMI (DOS Protected-Mode Interface) API to run on top of real-mode DOS systems and their emulations.
gdb supports native debugging of djgpp programs, and defines a few commands specific to the djgpp port. This subsection describes those commands.
This is a prefix of djgpp-specific commands which print information about the target system and important OS structures.
This command displays assorted information about the underlying platform: the CPU type and features, the OS version and flavor, the DPMI version, and the available conventional and DPMI memory.
These 3 commands display entries from, respectively, Global, Local, and Interrupt Descriptor Tables (GDT, LDT, and IDT). The descriptor tables are data structures which store a descriptor for each segment that is currently in use. The segment's selector is an index into a descriptor table; the table entry for that index holds the descriptor's base address and limit, and its attributes and access rights.
A typical djgpp program uses 3 segments: a code segment, a data segment (used for both data and the stack), and a DOS segment (which allows access to DOS/BIOS data structures and absolute addresses in conventional memory). However, the DPMI host will usually define additional segments in order to support the DPMI environment.
These commands allow to display entries from the descriptor tables. Without an argument, all entries from the specified table are displayed. An argument, which should be an integer expression, means display a single entry whose index is given by the argument. For example, here's a convenient way to display information about the debugged program's data segment:
(gdb) info dos ldt $ds 0x13f: base=0x11970000 limit=0x0009ffff 32-Bit Data (Read/Write, Exp-up)
|
This comes in handy when you want to see whether a pointer is outside the data segment's limit (that is, garbled).
These two commands display entries from, respectively, the Page Directory and the Page Tables. Page Directories and Page Tables are data structures which control how virtual memory addresses are mapped into physical addresses. A Page Table includes an entry for every page of memory that is mapped into the program's address space; there may be several Page Tables, each one holding up to 4096 entries. A Page Directory has up to 4096 entries, one each for every Page Table that is currently in use.
Without an argument, info dos pde displays the entire Page Directory, and info dos pte displays all the entries in all of the Page Tables. An argument, an integer expression, given to the info dos pde command means display only that entry from the Page Directory table. An argument given to the info dos pte command means display entries from a single Page Table, the one pointed to by the specified entry in the Page Directory.
These commands are useful when your program uses DMA (Direct Memory Access), which needs physical addresses to program the DMA controller.
These commands are supported only with some DPMI servers.
This command displays the Page Table entry for a specified linear address. The argument linear address addr should already have the appropriate segment's base address added to it, because this command accepts addresses which may belong to any segment. For example, here's how to display the Page Table entry for the page where the variable i is stored:
(gdb) info dos address-pte __djgpp_base_address + (char *)&i Page Table entry for address 0x11a00d30:
Base=0x02698000 Dirty Acc. Not-Cached Write-Back Usr Read-Write +0xd30
|
This says that i is stored at offset 0xd30 from the page whose physical base address is 0x02698000, and prints all the attributes of that page.
Note that you must cast the addresses of variables to a char *, since otherwise the value of __djgpp_base_address, the base address of all variables and functions in a djgpp program, will be added using the rules of C pointer arithmetics: if i is declared an int, gdb will add 4 times the value of __djgpp_base_address to the address of i.
Here's another example, it displays the Page Table entry for the transfer buffer:
(gdb) info dos address-pte *((unsigned *)&_go32_info_block + 3) Page Table entry for address 0x29110:
Base=0x00029000 Dirty Acc. Not-Cached Write-Back Usr Read-Write +0x110
|
(The + 3 offset is because the transfer buffer's address is the 3rd member of the _go32_info_block structure.) The output of this command clearly shows that addresses in conventional memory are mapped 1:1, that is, the physical and linear addresses are identical.
This command is supported only with some DPMI servers.
gdb supports native debugging of MS Windows programs, including DLLs with and without symbolic debugging information. There are various additional Cygwin-specific commands, described in this subsection. The subsubsection (refer to Section 20.1.4.1 Support for DLLs without debugging symbols describes working with DLLs that have no debugging symbols.
This is a prefix of MS Windows specific commands which print information about the target system and important OS structures.
This command displays information returned by the Win32 API GetThreadSelectorEntry function. It takes an optional argument that is evaluated to a long value to give the information about this given selector. Without argument, this command displays information about the the six segment registers.
This is a Cygwin specific alias of info shared.
This command loads symbols from a dll similarly to add-sym command but without the need to specify a base address.
If mode is on the debuggee will be started in a new console on next start. If mode is offi, the debuggee will be started in the same console as the debugger.
Displays whether a new console is used when the debuggee is started.
This boolean value controls whether the debuggee should start a new group or stay in the same group as the debugger. This affects the way the Windows OS handles Ctrl-C.
Displays current value of new-group boolean.
This boolean value adds debug output concerning events seen by the debugger.
This boolean value adds debug output concerning execute events seen by the debugger.
This boolean value adds debug ouptut concerning exception events seen by the debugger.
This boolean value adds debug ouptut concerning memory events seen by the debugger.
This boolean values specifies whether the debuggee is called via a shell or directly (default value is on).
Displays if the debuggee will be started with a shell.
Very often on windows, some of the DLLs that your program relies on do not include symbolic debugging information (for example, kernel32.dll). When gdb doesn't recognize any debugging symbols in a DLL, it relies on the minimal amount of symbolic information contained in the DLL's export table. This subsubsection describes working with such symbols, known internally to gdb as "minimal symbols".
Note that before the debugged program has started execution, no DLLs will have been loaded. The easiest way around this problem is simply to start the program -- either by setting a breakpoint or letting the program run once to completion. It is also possible to force gdb to load a particular DLL before starting the executable -- see the shared library information in (refer to Section 17.1 Commands to specify files or the dll-symbols command in (refer to Section 20.1.4 Features for Debugging MS Windows PE executables. Currently, explicitly loading symbols from a DLL with no debugging information will cause the symbol names to be duplicated in gdb's lookup table, which may adversely affect symbol lookup performance.
In keeping with the naming conventions used by the Microsoft debugging tools, DLL export symbols are made available with a prefix based on the DLL name, for instance KERNEL32!CreateFileA. The plain name is also entered into the symbol table, so CreateFileA is often sufficient. In some cases there will be name clashes within a program (particularly if the executable itself includes full debugging symbols) necessitating the use of the fully qualified name when referring to the contents of the DLL. Use single-quotes around the name to avoid the exclamation mark ("!") being interpreted as a language operator.
Note that the internal name of the DLL may be all upper-case, even though the file name of the DLL is lower-case, or vice-versa. Since symbols within gdb are case-sensitive this may cause some confusion. If in doubt, try the info functions and info variables commands or even maint print msymbols ((refer to Chapter 15 Examining the Symbol Table). Here's an example:
(gdb) info function CreateFileA All functions matching regular expression "CreateFileA": Non-debugging symbols: 0x77e885f4 CreateFileA 0x77e885f4 KERNEL32!CreateFileA |
(gdb) info function ! All functions matching regular expression "!": Non-debugging symbols: 0x6100114c cygwin1!__assert 0x61004034 cygwin1!_dll_crt0@0 0x61004240 cygwin1!dll_crt0(per_process *) [etc...] |
Symbols extracted from a DLL's export table do not contain very much type information. All that gdb can do is guess whether a symbol refers to a function or variable depending on the linker section that contains the symbol. Also note that the actual contents of the memory contained in a DLL are not available unless the program is running. This means that you cannot examine the contents of a variable or disassemble a function within a DLL without a running program.
Variables are generally treated as pointers and dereferenced automatically. For this reason, it is often necessary to prefix a variable name with the address-of operator ("&") and provide explicit type information in the command. Here's an example of the type of problem:
(gdb) print 'cygwin1!__argv' $1 = 268572168 |
(gdb) x 'cygwin1!__argv' 0x10021610: "\230y\"" |
And two possible solutions:
(gdb) print ((char **)'cygwin1!__argv')[0] $2 = 0x22fd98 "/cygdrive/c/mydirectory/myprogram" |
(gdb) x/2x &'cygwin1!__argv' 0x610c0aa8 <cygwin1!__argv>: 0x10021608 0x00000000 (gdb) x/x 0x10021608 0x10021608: 0x0022fd98 (gdb) x/s 0x0022fd98 0x22fd98: "/cygdrive/c/mydirectory/myprogram" |
Setting a break point within a DLL is possible even before the program starts execution. However, under these circumstances, gdb can't examine the initial instructions of the function in order to skip the function's frame set-up code. You can work around this by using "*&" to set the breakpoint at a raw memory address:
(gdb) break *&'python22!PyOS_Readline' Breakpoint 1 at 0x1e04eff0 |
The author of these extensions is not entirely convinced that setting a break point within a shared DLL like kernel32.dll is completely safe.