This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: remote debugging packets
- From: Mark Salter <msalter at redhat dot com>
- To: manojv at noida dot hcltech dot com
- Cc: gdb at sources dot redhat dot com
- Date: Sat, 22 Nov 2003 08:46:53 -0500 (EST)
- Subject: Re: remote debugging packets
- References: <1B3885BC15C7024C845AAC78314766C5010336EC@EXCH-01>
> 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
>>