[RFC] problem fetching inferior memory due to breakpoint
Eli Zaretskii
eliz@gnu.org
Sat Apr 29 14:14:00 GMT 2006
> 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.
More information about the Gdb-patches
mailing list