This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
RE: remote debugging packets
- From: "Manoj Verma, Noida" <manojv at noida dot hcltech dot com>
- To: Mark Salter <msalter at redhat dot com>
- Cc: gdb at sources dot redhat dot com
- Date: Sat, 22 Nov 2003 14:17:27 +0530
- Subject: RE: remote debugging packets
Do you mean to indicate that the debugger may not stop at line #YY in this
case?
> -----Original Message-----
> From: Mark Salter [mailto:msalter@redhat.com]
> Sent: Friday, November 21, 2003 9:37 PM
> To: manojv@noida.hcltech.com
> Cc: gdb@sources.redhat.com
> Subject: Re: remote debugging packets
>
>
> >>>>> Manoj Verma, Noida writes:
>
> > Let me explain my concern in this way...
> > I have following C snippet:
>
> > ...
> > for(i=0; i<100; i++) // say line #xx
> > *b0++ = *b1++; // say line #yy
> > ...
>
> > and the assembly instruction corresponding to it is:
>
> > ...
> > lc = 100;
> > rep(lc) *b0++ = *b1++;
> > ...
>
> > I set the breakpoint to both of these lines xx & yy.
>
> > Now when I am at XX, I say 'Continue'. If it steps first
> then it comes to
> > line #yy. Then if it continues, then I will not see my
> program stopping at
> > YY where it should.
>
> > Or is it like, before proceeding from line #YY the debugger
> looks for some
> > traps present at that particular line and then continues..
>
> > Pl. correct me if I am wrong.
>
> If compiler optimization causes the loop to be executed as a
> single machine instruction (as in your example), then there is
> nothing GDB can do about it. GDB's behavior would be to stop
> after the loop finishes because the loop is actually one machine
> instruction. This seems reasonable to me.
>
> --Mark
>