18.1.5.3 Working with Minimal Symbols

Symbols extracted from a DLL's export table do not contain very much type information. All that No value for GDBN 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:

(No value for GDBP) print 'cygwin1!__argv'
$1 = 268572168

(No value for GDBP) x 'cygwin1!__argv'
0x10021610:      "\230y\""

And two possible solutions:

(No value for GDBP) print ((char **)'cygwin1!__argv')[0]
$2 = 0x22fd98 "/cygdrive/c/mydirectory/myprogram"

(No value for GDBP) x/2x &'cygwin1!__argv'
0x610c0aa8 <cygwin1!__argv>:    0x10021608      0x00000000
(No value for GDBP) x/x 0x10021608
0x10021608:     0x0022fd98
(No value for GDBP) 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, No value for GDBN 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:

(No value for GDBP) 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.