[prev in list] [next in list] [prev in thread] [next in thread] 

List:       gdb
Subject:    Re: remote debugging packets
From:       Mark Salter <msalter () redhat ! com>
Date:       2003-11-22 13:46:53
Message-ID: 20031122134653.4D2E17879F () deneb ! localdomain
[Download RAW message or body]


> Do you mean to indicate that the debugger may not stop at line #YY in this
> case?

If I understand you, it would stop at #xx. If you step or continue,
it would stop at #yy. On a step or continue from #yy, it would stop
at #zz. It would not stop at #yy again because #yy is one machine
instruction.

--Mark

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

[prev in list] [next in list] [prev in thread] [next in thread]