RE: remote debugging packets

RE: remote debugging packets

[Manoj Verma, Noida]

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.

Thanks..

> -----Original Message-----
> From: Mark Salter [mailto:msalter@redhat.com]
> Sent: Friday, November 21, 2003 8:22 PM
> To: manojv@noida.hcltech.com
> Cc: gdb@sources.redhat.com
> Subject: Re: remote debugging packets
> 
> 
> >>>>> Manoj Verma, Noida writes:
> 
> >> > 2) On the Gdb client side when I continue, "(gdb) 
> >> continue", why it first
> >> > sends a packet ($s#73...Ack) and then the packet 
> >> ($c#63...Ack) as shown
> >> > below in sanpshot-2 ? It should only send the packet 
> ($c#63...Ack).
> >> 
> >> This is expected. GDB has to single-step past the one machine 
> >> instruction
> >> before re-inserting any breakpoints and continuing.
> >> 
> 
> > But consider the scenario when I have breakpoints set on 
> two consecutive
> > lines. Will in this case also this behavior is justified?
> 
> It is certainly correct behavior. I don't see any problem with
> your scenario.
> 
> --Mark
> 
> 

Re: remote debugging packets

[Mark Salter]

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

RE: remote debugging packets

[Manoj Verma, Noida]

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
> 

Re: remote debugging packets

[Ramana Radhakrishnan]

Manoj Verma, Noida wrote:

>Do you mean to indicate that the debugger may not stop at line #YY in this
>case?
>  
>
Since line xx and yy match to the same pc, only one breakpoint can be 
set and it would hit only once. It would be equivalent to putting 
duplicate breakpoints. This is because your architecture seems to have 
this loop instruction.

cheers
Ramana

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

Re: remote debugging packets

[Mark Salter]

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

RE: remote debugging packets

[Manoj Verma, Noida]

> -----Original Message-----
> From: Mark Salter [mailto:msalter@redhat.com]
> Sent: Friday, November 21, 2003 7:56 PM
> To: manojv@noida.hcltech.com
> Cc: gdb@sources.redhat.com
> Subject: Re: remote debugging packets
> 
> 
> >>>>> Manoj Verma, Noida writes:
> 
> > My question is, 
> > 1) I did the "step" only once but why there are three 
> packets (sometimes two
> > packets) corresponding to the "step" ($s#73...Ack) as shown below in
> > sanpshot-1, evenif the correct response is received for the 
> first packet. 
> 
> "step" is used to step past a line of source code. The $s packet tells
> the target to step past a machine instruction. Apparently in 
> this case,
> the source code line corresponds to three machine instructions.
> 

This is fine.

> > 2) On the Gdb client side when I continue, "(gdb) 
> continue", why it first
> > sends a packet ($s#73...Ack) and then the packet 
> ($c#63...Ack) as shown
> > below in sanpshot-2 ? It should only send the packet ($c#63...Ack).
> 
> This is expected. GDB has to single-step past the one machine 
> instruction
> before re-inserting any breakpoints and continuing.
> 

But consider the scenario when I have breakpoints set on two consecutive
lines. Will in this case also this behavior is justified?

> --Mark
> 

Re: remote debugging packets

[Mark Salter]

>>>>> Manoj Verma, Noida writes:

>> > 2) On the Gdb client side when I continue, "(gdb) 
>> continue", why it first
>> > sends a packet ($s#73...Ack) and then the packet 
>> ($c#63...Ack) as shown
>> > below in sanpshot-2 ? It should only send the packet ($c#63...Ack).
>> 
>> This is expected. GDB has to single-step past the one machine 
>> instruction
>> before re-inserting any breakpoints and continuing.
>> 

> But consider the scenario when I have breakpoints set on two consecutive
> lines. Will in this case also this behavior is justified?

It is certainly correct behavior. I don't see any problem with
your scenario.

--Mark

remote debugging packets

[Manoj Verma, Noida]

Hi,
I am doing remote debugging using GDB server over ethernet. Both host and
target are i386-linux machines.

On the Gdb client side: 
(gdb) break main
(gdb) set debug remote 1
(gdb) step

I see the following (Snapshot-1) packet transaction between Gdb client and
Gdb server. 

My question is, 
1) I did the "step" only once but why there are three packets (sometimes two
packets) corresponding to the "step" ($s#73...Ack) as shown below in
sanpshot-1, evenif the correct response is received for the first packet. 

2) On the Gdb client side when I continue, "(gdb) continue", why it first
sends a packet ($s#73...Ack) and then the packet ($c#63...Ack) as shown
below in sanpshot-2 ? It should only send the packet ($c#63...Ack).

Kindly clarify. 


******************************** Sanpshot-1
*********************************
(gdb) s
Sending packet: $m4000e4f0,1#bd...Ack
Packet received: 55
Sending packet: $M4000e4f0,1:cc#9d...Ack
Packet received: OK
Sending packet: $m40050444,1#5f...Ack
Packet received: 55
Sending packet: $M40050444,1:cc#3f...Ack
Packet received: OK
Sending packet: $s#73...Ack
Packet received: T0505:b8faffbf;04:a0faffbf;08:85840408;
Sending packet: $s#73...Ack
Packet received: T0505:b8faffbf;04:a0faffbf;08:88840408;
Sending packet: $s#73...Ack
Packet received: T0505:b8faffbf;04:a0faffbf;08:8b840408;
Sending packet: $M4000e4f0,1:55#41...Ack
Packet received: OK
Sending packet: $M40050444,1:55#e3...Ack
Packet received: OK
16              z += func1();

****************************************************************************
****

and 

******************************** Sanpshot-2
*********************************
(gdb) c
Continuing.
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $s#73...Ack
Packet received: T0505:b8faffbf;04:98faffbf;08:f5840408;
Sending packet: $m8048466,1#3e...Ack
Packet received: c7
Sending packet: $M8048466,1:cc#1e...Ack
Packet received: OK
Sending packet: $m80484ce,1#9a...Ack
Packet received: c7
Sending packet: $M80484ce,1:cc#7a...Ack
Packet received: OK
Sending packet: $m4000e4f0,1#bd...Ack
Packet received: 55
Sending packet: $M4000e4f0,1:cc#9d...Ack
Packet received: OK
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $c#63...Ack
Packet received: T0505:98faffbf;04:8cfaffbf;08:fb840408;

****************************************************************************
****

Any clarification would be appreciated.

Re: remote debugging packets

[Mark Salter]

>>>>> Manoj Verma, Noida writes:

> My question is, 
> 1) I did the "step" only once but why there are three packets (sometimes two
> packets) corresponding to the "step" ($s#73...Ack) as shown below in
> sanpshot-1, evenif the correct response is received for the first packet. 

"step" is used to step past a line of source code. The $s packet tells
the target to step past a machine instruction. Apparently in this case,
the source code line corresponds to three machine instructions.

> 2) On the Gdb client side when I continue, "(gdb) continue", why it first
> sends a packet ($s#73...Ack) and then the packet ($c#63...Ack) as shown
> below in sanpshot-2 ? It should only send the packet ($c#63...Ack).

This is expected. GDB has to single-step past the one machine instruction
before re-inserting any breakpoints and continuing.

--Mark