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.
20.1. Native
This section describes details specific to particular native
configurations.
20.1.1. HP-UX
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.
20.1.2. SVR4 process information
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.
info proc
Summarize available information about the process.
info proc mappings
Report on the address ranges accessible in the program, with information
on whether your program may read, write, or execute each range.
20.1.3. Features for Debugging djgpp Programs
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.
info dos
This is a prefix of djgpp-specific commands which print
information about the target system and important OS structures.
info dos sysinfo
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.
info dos gdt, info dos ldt, info dos idt
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 $ds0x13f: 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).
info dos pde, info dos pte
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.
info dos address-pte addr
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 *)&iPage 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.
20.1.4. Features for Debugging MS Windows PE executables
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.
info w32
This is a prefix of MS Windows specific commands which print
information about the target system and important OS structures.
info w32 selector
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.
info dll
This is a Cygwin specific alias of info shared.
dll-symbols
This command loads symbols from a dll similarly to
add-sym command but without the need to specify a base address.
set new-console mode
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.
show new-console
Displays whether a new console is used
when the debuggee is started.
set new-group mode
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.
show new-group
Displays current value of new-group boolean.
set debugevents
This boolean value adds debug output concerning events seen by the debugger.
set debugexec
This boolean value adds debug output concerning execute events
seen by the debugger.
set debugexceptions
This boolean value adds debug ouptut concerning exception events
seen by the debugger.
set debugmemory
This boolean value adds debug ouptut concerning memory events
seen by the debugger.
set shell
This boolean values specifies whether the debuggee is called
via a shell or directly (default value is on).
show shell
Displays if the debuggee will be started with a shell.
20.1.4.1. Support for DLLs without debugging symbols
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.
20.1.4.2. DLL name prefixes
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...]
20.1.4.3. Working with minimal symbols
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:
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.
