[RFC] problem fetching inferior memory due to breakpoint

[RFC] problem fetching inferior memory due to breakpoint

[Joel Brobecker]

Hello,

This happens on Windows XP with the cygwin debugger. Consider the
following code:

        #include <stdio.h>
        
        void
        hello (void)
        {
          printf ("Hello world.\n");
        }
        
        int
        main (void)
        {
          hello ();
        
          return 0;
        }

Break at the first instruction of hello(), and then do a couple of
stepi's:

        (gdb) b *hello
        Breakpoint 1 at 0x401050: file foo.c, line 5.
        (gdb) run
        Starting program: /[...]/foo.exe 
        
        Breakpoint 1, hello () at foo.c:5
        5       {
        (gdb) stepi
        0x00401051      5       {
        (gdb) bt
        #0  0x00401051 in hello () at foo.c:5
        #1  0x00401093 in main () at foo.c:12
        (gdb) stepi
        0x00401053 in hello () at foo.c:5
        5       {

So we're at the third instruction of the function. Here is the backtrace
we get when I request it:

        (gdb) bt
        #0  0x00401053 in hello () at foo.c:5
        #1  0x0022ee88 in ?? ()
        #2  0x00401093 in main () at foo.c:12

We get an extra frame between hello() and main().

The reason for this is that the i386 code tries to scan the prologue
of hello during the step operation. So it tries reading the first few
bytes of the function, and hits a snag, because at the time when we do
the memory read, the breakpoint instruction is still inserted, and hence
we fail to recognize the prologue....

We actually scan the function prologue during the step operation as
opposed to during the "bt", because we need to determine where we are,
and that causes us to create the frame ID for frame 0, which means
scanning the function prologue (not actually verified, all from memory,
may be incorrect - but the fact is correct: we compute the frame ID
during the step).

I'm not exactly sure yet as to why we don't see this problem on x86-linux.
But all works fine there as far as I can tell.

I'm not entirely sure as to how to fix this problem. Since this problem
seems confined to win32, perhaps the fix should be in win32-nat.c, in
the xfer_memory routine, when I would then have to check for breakpoints.
Seems ok, except that I would then end up duplicating the logic of
deprecated_read_memory_nobpt.

I looked at the gdb-patches archives, and Andrew said at the time
that we should use get_frame_memory. The problem is that I don't see
how get_frame_memory() will help, since all it does is calling
read_memory(), which brings us back to our initial problem.

The simplest solution that seems to work is to modify read_memory to
use deprecated_read_memory_nobpt() instead of target_read_memory().
Seems a bit of a shame to check all breakpoints for each and every
memory read, though... But the overhead should be pretty negligible,
assuming that most sessions only have a few breakpoints, not millions of
them. Perhaps add a check for breakpoints inserted before doing the
breakpoints check.

Another solution would be have the win32 native code remove breakpoints
when handling all events, and then re-insert them as we resume execution.
Seems dangerous because we may miss some resume entry points.

We could apply this same later idea to the generic code instead of the
win32 code. Perhaps other targets are affected as well. But I suspect
that this would negatively impact certain targets that wouldn't need
this, especially remote targets with a slow communication link.

Any suggestions?

Thanks,
-- 
Joel

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

[Daniel Jacobowitz]

On Wed, Apr 26, 2006 at 12:05:17PM -0700, Joel Brobecker wrote:
> We actually scan the function prologue during the step operation as
> opposed to during the "bt", because we need to determine where we are,
> and that causes us to create the frame ID for frame 0, which means
> scanning the function prologue (not actually verified, all from memory,
> may be incorrect - but the fact is correct: we compute the frame ID
> during the step).

Which seriously blows for performance.

> I'm not exactly sure yet as to why we don't see this problem on x86-linux.
> But all works fine there as far as I can tell.

Try removing .debug_frame, to trigger the prologue analyzer?

> I looked at the gdb-patches archives, and Andrew said at the time
> that we should use get_frame_memory. The problem is that I don't see
> how get_frame_memory() will help, since all it does is calling
> read_memory(), which brings us back to our initial problem.

Try safe_frame_unwind_memory, the other caller of
deprecated_read_memory_nobpt.  Many other prologue analyzers already
seem to use that.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Joel Brobecker]

> Try safe_frame_unwind_memory, the other caller of
> deprecated_read_memory_nobpt.  Many other prologue analyzers already
> seem to use that.

Humpf, I must have been sleeping when I did my grep for this function
as I should have seen that too.

Do you think I should modify win32-nat to use that function or should
I modify read_memory() to use safe_frame_unwind_memory(). I prefer
the latter, because we also protect other platforms where this may
happen too.

-- 
Joel

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

[Daniel Jacobowitz]

On Wed, Apr 26, 2006 at 02:18:17PM -0700, Joel Brobecker wrote:
> > Try safe_frame_unwind_memory, the other caller of
> > deprecated_read_memory_nobpt.  Many other prologue analyzers already
> > seem to use that.
> 
> Humpf, I must have been sleeping when I did my grep for this function
> as I should have seen that too.
> 
> Do you think I should modify win32-nat to use that function or should
> I modify read_memory() to use safe_frame_unwind_memory(). I prefer
> the latter, because we also protect other platforms where this may
> happen too.

Neither, where in win32-nat were you planning to modify?  Presumably
you should change the i386 prologue analyzer.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Joel Brobecker]

> Neither, where in win32-nat were you planning to modify?  Presumably
> you should change the i386 prologue analyzer.

Aaahh, not win32-nat, but i386-tdep, in the prologue analyzer.
If this is the prefered method, then I think you can expect a patch
for tomorrow.

-- 
Joel

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

[Daniel Jacobowitz]

On Wed, Apr 26, 2006 at 03:18:01PM -0700, Joel Brobecker wrote:
> > Neither, where in win32-nat were you planning to modify?  Presumably
> > you should change the i386 prologue analyzer.
> 
> Aaahh, not win32-nat, but i386-tdep, in the prologue analyzer.
> If this is the prefered method, then I think you can expect a patch
> for tomorrow.

I think that's the right fix.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Michael Snyder]

Daniel Jacobowitz wrote:
> On Wed, Apr 26, 2006 at 03:18:01PM -0700, Joel Brobecker wrote:
> 
>>>Neither, where in win32-nat were you planning to modify?  Presumably
>>>you should change the i386 prologue analyzer.
>>
>>Aaahh, not win32-nat, but i386-tdep, in the prologue analyzer.
>>If this is the prefered method, then I think you can expect a patch
>>for tomorrow.
> 
> 
> I think that's the right fix.
> 

You know what might be a good optimization?

Take "breakpoints_inserted" out of infcmd, stick it in breakpoint.c,
and export an access method.  It makes no sense for anybody except
breakpoint.c to be keeping track of this anyway.

Then, read_memory_no_bpt can simply check this, and if it's not set,
default to target_read_memory.

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

[Daniel Jacobowitz]

On Wed, Apr 26, 2006 at 04:33:12PM -0700, Michael Snyder wrote:
> You know what might be a good optimization?
> 
> Take "breakpoints_inserted" out of infcmd, stick it in breakpoint.c,
> and export an access method.  It makes no sense for anybody except
> breakpoint.c to be keeping track of this anyway.
> 
> Then, read_memory_no_bpt can simply check this, and if it's not set,
> default to target_read_memory.

True - but not in the big picture.  If there's enough breakpoints that
walking the linked list checking ->inserted is a problem, think how
much more of a problem removing them and inserting them every step time
must be.  The nice thing about keeping it private in infrun.c is no one
else will use it...

I don't think we're going to be able to keep being so cavalier with
removing and reinserting breakpoints.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Jim Blandy]

On 4/26/06, Daniel Jacobowitz <drow@false.org> wrote:
> Try safe_frame_unwind_memory, the other caller of
> deprecated_read_memory_nobpt.  Many other prologue analyzers already
> seem to use that.

Prologue analyzers get called in two contexts, though: from the
skip_prologue gdbarch method, and from the frame unwinding stuff.  In
the former case, there's no frame at hand to use; there may not even
be a program running, if the user is setting breakpoints before doing
a 'run'.  I'm happy to pass a frame to my analyzer, use
safe_frame_unwind_memory when it's non-null, and target_read_memory
when it's null, but this seems klunky.

The whole reason safe_frame_unwind_memory takes a frame argument at
all is that, in the future (at present it ignores its frame argument)
the frame will identify which process/address space to read.  But
using frames for this isn't good enough, because, as skip_prologue
shows, we also need to be able to read memory when there are no frames
present.

Some of this was discussed here:
http://sourceware.org/ml/gdb/2005-11/msg00628.html

Ideally, the arch's skip_prologue function would take, in addition to
a CORE_ADDR, one of my imaginary address space objects.  Or, CORE_ADDR
would become a struct carrying an address space object and an offset
within that address space.  Then the CORE_ADDR alone would be enough
to do the read.  You could have address space objects representing the
memory loaded by a shared library, or sections of a relocatable
object, as well as live processes' address spaces.

If GDB were written in C++, we could overload +, -, etc. on CORE_ADDR
and write trim source for bloated object code... but my floor time is
up, and I defer to my esteemed (and more practical-minded) colleagues.

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

[Michael Snyder]

Daniel Jacobowitz wrote:
> On Wed, Apr 26, 2006 at 04:33:12PM -0700, Michael Snyder wrote:
> 
>>You know what might be a good optimization?
>>
>>Take "breakpoints_inserted" out of infcmd, stick it in breakpoint.c,
>>and export an access method.  It makes no sense for anybody except
>>breakpoint.c to be keeping track of this anyway.
>>
>>Then, read_memory_no_bpt can simply check this, and if it's not set,
>>default to target_read_memory.
> 
> 
> True - but not in the big picture.  If there's enough breakpoints that
> walking the linked list checking ->inserted is a problem, think how
> much more of a problem removing them and inserting them every step time
> must be.  

I must not have made myself clear.  I didn't mean to suggest any change
as to when or how often breakpoints are inserted.  My suggestion relates
to when and how often we would have to walk the list of breakpoints
before reading memory.

If the breakpoints_inserted flag were made globally available
(thru an accessor method, of course), then there is a really
inexpensive way to determine that the list-walking step may
be skipped.

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

[Daniel Jacobowitz]

On Wed, Apr 26, 2006 at 06:37:14PM -0700, Michael Snyder wrote:
> If the breakpoints_inserted flag were made globally available
> (thru an accessor method, of course), then there is a really
> inexpensive way to determine that the list-walking step may
> be skipped.

Right, but my point is that the concept of an "all breakpoints are
inserted" flag may have its days numbered.  If we want to scale
to large numbers of breakpoints - e.g. on an inlined function -
I don't think we can remove all breakpoints.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Eli Zaretskii]

> Date: Wed, 26 Apr 2006 12:05:17 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> 
> Break at the first instruction of hello(), and then do a couple of
> stepi's:
> 
>         (gdb) b *hello
>         Breakpoint 1 at 0x401050: file foo.c, line 5.
>         (gdb) run
>         Starting program: /[...]/foo.exe 
>         
>         Breakpoint 1, hello () at foo.c:5
>         5       {
>         (gdb) stepi
>         0x00401051      5       {
>         (gdb) bt
>         #0  0x00401051 in hello () at foo.c:5
>         #1  0x00401093 in main () at foo.c:12
>         (gdb) stepi
>         0x00401053 in hello () at foo.c:5
>         5       {
> 
> So we're at the third instruction of the function. Here is the backtrace
> we get when I request it:
> 
>         (gdb) bt
>         #0  0x00401053 in hello () at foo.c:5
>         #1  0x0022ee88 in ?? ()
>         #2  0x00401093 in main () at foo.c:12
> 
> We get an extra frame between hello() and main().

I cannot reproduce this with a MinGW-compiled program, using GDB 6.3
and 6.3.50.20051116-cvs.  What version of GDB are you using?  Is this
problem visible only in a recent codebase?

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

[Joel Brobecker]

> >         (gdb) bt
> >         #0  0x00401053 in hello () at foo.c:5
> >         #1  0x0022ee88 in ?? ()
> >         #2  0x00401093 in main () at foo.c:12
> > 
> > We get an extra frame between hello() and main().
> 
> I cannot reproduce this with a MinGW-compiled program, using GDB 6.3
> and 6.3.50.20051116-cvs.  What version of GDB are you using?  Is this
> problem visible only in a recent codebase?

Right now, I'm working on 6.4.50.20060426-cvs. I would pretty surprised
if 6.3 didn't have the problem, I remember giving it a try too.

-- 
Joel

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

[Eli Zaretskii]

> Date: Thu, 27 Apr 2006 13:56:21 -0700
> From: Joel Brobecker <brobecker@adacore.com>
> Cc: gdb-patches@sources.redhat.com
> 
> > >         (gdb) bt
> > >         #0  0x00401053 in hello () at foo.c:5
> > >         #1  0x0022ee88 in ?? ()
> > >         #2  0x00401093 in main () at foo.c:12
> > > 
> > > We get an extra frame between hello() and main().
> > 
> > I cannot reproduce this with a MinGW-compiled program, using GDB 6.3
> > and 6.3.50.20051116-cvs.  What version of GDB are you using?  Is this
> > problem visible only in a recent codebase?
> 
> Right now, I'm working on 6.4.50.20060426-cvs. I would pretty surprised
> if 6.3 didn't have the problem

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?

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

[Joel Brobecker]

> 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

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

[Daniel Jacobowitz]

On Fri, Apr 28, 2006 at 10:00:01AM -0700, Joel Brobecker wrote:
> 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

FWIW, I get the same result.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Eli Zaretskii]

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

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

[Eli Zaretskii]

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

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

[Daniel Jacobowitz]

On Sat, Apr 29, 2006 at 05:13:49PM +0300, Eli Zaretskii wrote:
> 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

That's why.  Your Cygwin compiler uses DWARF-2 unwinding; therefore the
prologue analyzer is never even invoked.  Try using -gstabs instead of
-gdwarf-2 (or not using -g at all), and I bet you'll see the problem.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Eli Zaretskii]

> Date: Sat, 29 Apr 2006 10:20:38 -0400
> From: Daniel Jacobowitz <drow@false.org>
> Cc: Joel Brobecker <brobecker@adacore.com>, gdb-patches@sources.redhat.com
> 
> That's why.  Your Cygwin compiler uses DWARF-2 unwinding; therefore the
> prologue analyzer is never even invoked.  Try using -gstabs instead of
> -gdwarf-2 (or not using -g at all), and I bet you'll see the problem.

Right you are.  (Btw, it's not a Cygwin compiler, it's a MinGW
compiler.)

The MinGW compiler uses stabs by default.  I used an explicit
"-gdwarf-2" switch because I couldn't imagine the Cygwin port doesn't
use DWARF-2.  Why doesn't it?  (Not that it's related to the issue at
hand.)

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

[Daniel Jacobowitz]

On Sat, Apr 29, 2006 at 05:48:23PM +0300, Eli Zaretskii wrote:
> The MinGW compiler uses stabs by default.  I used an explicit
> "-gdwarf-2" switch because I couldn't imagine the Cygwin port doesn't
> use DWARF-2.  Why doesn't it?  (Not that it's related to the issue at
> hand.)

IIRC, working DWARF-2 for Cygwin is extremely recent.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Daniel Jacobowitz]

On Sat, Apr 29, 2006 at 05:48:23PM +0300, Eli Zaretskii wrote:
> The MinGW compiler uses stabs by default.  I used an explicit
> "-gdwarf-2" switch because I couldn't imagine the Cygwin port doesn't
> use DWARF-2.  Why doesn't it?  (Not that it's related to the issue at
> hand.)

IIRC, working DWARF-2 for Cygwin is extremely recent.

-- 
Daniel Jacobowitz
CodeSourcery

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

[Eli Zaretskii]

> Date: Sat, 29 Apr 2006 11:06:25 -0400
> From: Daniel Jacobowitz <drow@false.org>
> 
> On Sat, Apr 29, 2006 at 05:48:23PM +0300, Eli Zaretskii wrote:
> > The MinGW compiler uses stabs by default.  I used an explicit
> > "-gdwarf-2" switch because I couldn't imagine the Cygwin port doesn't
> > use DWARF-2.  Why doesn't it?  (Not that it's related to the issue at
> > hand.)
> 
> IIRC, working DWARF-2 for Cygwin is extremely recent.

I doubt that it's more recent than in MinGW.  And I thought, since it
is supported now, everybody on this list will use it (I know _I_ do).

But as I said, this is a side note.