From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30231 invoked by alias); 28 Apr 2006 17:00:12 -0000 Received: (qmail 30180 invoked by uid 22791); 28 Apr 2006 17:00:10 -0000 X-Spam-Check-By: sourceware.org Received: from nile.gnat.com (HELO nile.gnat.com) (205.232.38.5) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 28 Apr 2006 17:00:06 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-nile.gnat.com (Postfix) with ESMTP id 566A348CE11; Fri, 28 Apr 2006 13:00:03 -0400 (EDT) Received: from nile.gnat.com ([127.0.0.1]) by localhost (nile.gnat.com [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 12899-01-6; Fri, 28 Apr 2006 13:00:03 -0400 (EDT) Received: from takamaka.act-europe.fr (s142-179-108-108.bc.hsia.telus.net [142.179.108.108]) by nile.gnat.com (Postfix) with ESMTP id D432A48CE08; Fri, 28 Apr 2006 13:00:02 -0400 (EDT) Received: by takamaka.act-europe.fr (Postfix, from userid 507) id 179A347E7F; Fri, 28 Apr 2006 10:00:01 -0700 (PDT) Date: Fri, 28 Apr 2006 17:00:00 -0000 From: Joel Brobecker To: Eli Zaretskii Cc: gdb-patches@sources.redhat.com Subject: Re: [RFC] problem fetching inferior memory due to breakpoint Message-ID: <20060428170001.GE930@adacore.com> References: <20060426190517.GA930@adacore.com> <20060427205621.GD930@adacore.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4i Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-04/txt/msg00366.txt.bz2 > 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