Re: [RFC] problem fetching inferior memory due to breakpoint

[Eli Zaretskii <eliz@gnu.org>]

> Date: Fri, 28 Apr 2006 10:00:01 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb-patches@sources.redhat.com
> 
> Here is the info using the cygwin compiler. I used a MinGW compiler
> in my initial experiments, but it might be easier for you to have something
> close to what I used if I use the cygwin compiler:
> 
> % gcc -v -S -g foo.c 
> Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
> Configured with: /gcc/gcc-3.4.4/gcc-3.4.4-1/configure --verbose --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info --enable-languages=c,ada,c++,d,f77,java,objc --enable-nls --without-included-gettext --enable-version-specific-runtime-libs --without-x --enable-libgcj --disable-java-awt --with-system-zlib --enable-interpreter --disable-libgcj-debug --enable-threads=posix --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions --enable-hash-synchronization --enable-libstdcxx-debug : (reconfigured) 
> Thread model: posix
> gcc version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125)
>  /usr/lib/gcc/i686-pc-cygwin/3.4.4/cc1.exe -quiet -v -D__CYGWIN32__ -D__CYGWIN__ -Dunix -D__unix__ -D__unix -idirafter /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api -idirafter /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/../../include/w32api foo.c -quiet -dumpbase foo.c -mtune=pentiumpro -auxbase foo -g -version -o foo.s
> ignoring nonexistent directory "/usr/local/include"
> ignoring nonexistent directory "/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/include"
> ignoring duplicate directory "/usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../i686-pc-cygwin/lib/../../include/w32api"
> #include "..." search starts here:
> #include <...> search starts here:
>  /usr/lib/gcc/i686-pc-cygwin/3.4.4/include
>  /usr/include
>  /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api
> End of search list.
> GNU C version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125) (i686-pc-cygwin)
>         compiled by GNU C version 3.4.4 (cygming special) (gdc 0.12, using dmd 0.125).
> GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072

Here's mine:

    D:\usr\eli\data>gcc -v -S -g gdbt.c
    Reading specs from D:/usr/bin/../lib/gcc/mingw32/3.4.2/specs
    Configured with: ../gcc/configure --with-gcc --with-gnu-ld --with-gnu-as --host=mingw32 --target=mingw32 --prefix=/mingw --enable-threads --disable-nls --enable-languages=c,c++,f77,ada,objc,java --disable-win32-registry --disable-shared --enable-sjlj-exceptions --enable-libgcj --disable-java-awt --without-x --enable-java-gc=boehm --disable-libgcj-debug --enable-interpreter --enable-hash-synchronization --enable-libstdcxx-debug
    Thread model: win32
    gcc version 3.4.2 (mingw-special)
     D:/usr/bin/../libexec/gcc/mingw32/3.4.2/cc1.exe -quiet -v -iprefix D:\usr\bin/../lib/gcc/mingw32/3.4.2/ gdbt.c -quiet -dumpbase gdbt.c -auxbase gdbt -gdwarf-2 -version -o gdbt.s
    ignoring nonexistent directory "D:/usr/bin/../lib/gcc/mingw32/3.4.2/../../../../mingw32/include"
    ignoring nonexistent directory "/mingw/include"
    ignoring nonexistent directory "/mingw/include"
    ignoring nonexistent directory "/mingw/lib/gcc/mingw32/3.4.2/include"
    ignoring nonexistent directory "/mingw/mingw32/include"
    ignoring nonexistent directory "/mingw/include"
    #include "..." search starts here:
    #include <...> search starts here:
     D:/usr/bin/../lib/gcc/mingw32/3.4.2/../../../../include
     D:/usr/bin/../lib/gcc/mingw32/3.4.2/include
    End of search list.
    GNU C version 3.4.2 (mingw-special) (mingw32)
	    compiled by GNU C version 3.4.2 (mingw-special).
    GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=65445

> The assembly code for hello() is:
> 
>         _hello:
>         .stabn 68,0,5,LM1-_hello
>         LM1:
>                 pushl   %ebp
>                 movl    %esp, %ebp
>                 subl    $8, %esp
>         .stabn 68,0,6,LM2-_hello
>         LM2:
>                 movl    $LC0, (%esp)
>                 call    _printf
>         .stabn 68,0,7,LM3-_hello
>         LM3:
>                 leave
>                 ret

Here's what I get (from the .s file written by the above GCC command):

	.file	"gdbt.c"
	.section	.debug_abbrev,"dr"
Ldebug_abbrev0:
	.section	.debug_info,"dr"
Ldebug_info0:
	.section	.debug_line,"dr"
Ldebug_line0:
	.text
Ltext0:
	.section .rdata,"dr"
LC0:
	.ascii "Hello world.\12\0"
	.text
.globl _hello
	.def	_hello;	.scl	2;	.type	32;	.endef
_hello:
LFB10:
	.file 1 "gdbt.c"
	.loc 1 5 0
	pushl	%ebp
LCFI0:
	movl	%esp, %ebp
LCFI1:
	subl	$8, %esp
LCFI2:
	.loc 1 6 0
	movl	$LC0, (%esp)
	call	_printf
	.loc 1 7 0
	leave
	ret

Disassembly inside GDB gives this:

    (gdb) br *hello
    Breakpoint 1 at 0x401290: file gdbt.c, line 5.
    (gdb) run
    Starting program: D:\usr\eli\data/./gdbt.exe

    Breakpoint 1, hello () at gdbt.c:5
    5       {
    (gdb) disassemble
    Dump of assembler code for function hello:
    0x00401290 <hello+0>:   push   %ebp
    0x00401291 <hello+1>:   mov    %esp,%ebp
    0x00401293 <hello+3>:   sub    $0x8,%esp
    0x00401296 <hello+6>:   movl   $0x403000,(%esp)
    0x0040129d <hello+13>:  call   0x401810 <printf>
    0x004012a2 <hello+18>:  leave
    0x004012a3 <hello+19>:  ret
    End of assembler dump.

> Here is the transcript of my GDB session:
> 
>         (gdb) b *hello
>         Breakpoint 1 at 0x401050: file foo.c, line 5.
>         (gdb) run
>         Starting program: /home/gnatmail/brobecke/bt/foo.cygwin.exe 
>         
>         Breakpoint 1, hello () at foo.c:5
>         5       {
>         (gdb) stepi 2
>         0x00401053 in hello () at foo.c:5
>         5       {
>         (gdb) bt
>         #0  0x00401053 in hello () at foo.c:5
>         #1  0x0022ee78 in ?? ()
>         #2  0x00401093 in main () at foo.c:12
> 
> I am starting to think that you might have missed one of the details
> that cause this problem to show up. Here they are in a checklist form:
>   - break at the very start of the function
>   - make sure that the breakpoint is not removed
>     (either because you used "tbreak" or "del")
>   - stepi twice
>   - bt

I typed exactly the same commands as you did.  Here's my GDB session:

    D:\usr\eli\data>gdb ./gdbt.exe
    GNU gdb 6.3
    Copyright 2004 Free Software Foundation, Inc.
    GDB is free software, covered by the GNU General Public License, and you are
    welcome to change it and/or distribute copies of it under certain conditions.
    Type "show copying" to see the conditions.
    There is absolutely no warranty for GDB.  Type "show warranty" for details.
    This GDB was configured as "i686-pc-mingw32"...
    (gdb) b *hello
    Breakpoint 1 at 0x401290: file gdbt.c, line 5.
    (gdb) run
    Starting program: D:\usr\eli\data/./gdbt.exe

    Breakpoint 1, hello () at gdbt.c:5
    5       {
    (gdb) stepi 2
    0x00401293      5       {
    (gdb) bt
    #0  0x00401293 in hello () at gdbt.c:5
    #1  0x004012d3 in main () at gdbt.c:12

> Let me know if you still have some trouble reproducing the problem.

As you see, I do.