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

[Joel Brobecker <brobecker at adacore dot com>]

> Then this is very strange, since I don't think the two ports of GCC,
> the MinGW one and the Cygwin one, produce different code here.  We
> could compare disassembly, I guess.
> 
> What compilation switches did you use?  For that matter, can you
> compile with -v and post everything that GCC printed?

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

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 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

Let me know if you still have some trouble reproducing the problem.
I'm about to post a first patch to correct this, as I finally managed
to run the testsuite on windows all the way through...

-- 
Joel