single-stepping remote target fails

single-stepping remote target fails

[Chad Phillips]

I have rewritten basic support for MCORE for gdb-6.3.  Also, I have 
written a debug proxy application that accepts 'remote' connections from 
GDB via. socket and then manipulates the target using its JTAG/BDM 
interface.  Now for the problems....

Context: Code being executed on the target is in Flash.  As a result, I 
have only supported hardware breakpoints at this time.  Two hardware 
breakpoints are available through the MCORE JTAG port.

Problem 1.
Single stepping in C source only steps by single machine instruction.  I 
had expected that GDB might try to set breakpoints on the next 
instruction and then continue, but I see no such requests from GDB.  How 
does GDB cause single steps through C (any high level language) source?

Problem 2.
When I issue the step command (or si, n, ni) to the target, GDB does a 
_lot_ of memory reads.  It reads from the start of main up to the 
current PC (in main).  What is it doing, and how can I make it stop?

Thanks,
Chad

Re: single-stepping remote target fails

[Daniel Jacobowitz]

On Thu, Jun 23, 2005 at 11:18:28AM -0400, Chad Phillips wrote:
> Problem 1.
> Single stepping in C source only steps by single machine instruction.  I 
> had expected that GDB might try to set breakpoints on the next 
> instruction and then continue, but I see no such requests from GDB.  How 
> does GDB cause single steps through C (any high level language) source?

It does hardware single steps until the source line of the $pc changes.

> Problem 2.
> When I issue the step command (or si, n, ni) to the target, GDB does a 
> _lot_ of memory reads.  It reads from the start of main up to the 
> current PC (in main).  What is it doing, and how can I make it stop?

Preumably it is doing prologue analysis.  You need to work out (A) why
it triggered the prolgoue analyzer and (B) whether you should be using
unwind information instead of prologue analysis.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: single-stepping remote target fails

[Chad Phillips]

 >On Thu, Jun 23, 2005 at 11:18:28AM -0400, Chad Phillips wrote:
 >> Problem 1.
 >> Single stepping in C source only steps by single machine instruction.
 >> I had expected that GDB might try to set breakpoints on the next
 >> instruction and then continue, but I see no such requests from GDB.
 >> How does GDB cause single steps through C (any high level language)
 >> source?
 >It does hardware single steps until the source line of the $pc changes.

Interesting.  It makes no requests to set breakpoints.  If I explicitly 
set breakpoints, they work.   But when I issue the step command, I get 
no breakpoint commands at my proxy application from GDB.  Any Ideas?

 >> Problem 2.
 >> When I issue the step command (or si, n, ni) to the target, GDB does
 >> a _lot_ of memory reads.  It reads from the start of main up to the
 >> current PC (in main).  What is it doing, and how can I make it stop?

 >Preumably it is doing prologue analysis.  You need to work out (A) why
 >it triggered the prolgoue analyzer and (B) whether you should be using
 >unwind information instead of prologue analysis.

Thanks.  That make sense.

-Chad

Re: single-stepping remote target fails

[Daniel Jacobowitz]

On Thu, Jun 23, 2005 at 11:40:49AM -0400, Chad Phillips wrote:
> >On Thu, Jun 23, 2005 at 11:18:28AM -0400, Chad Phillips wrote:
> >> Problem 1.
> >> Single stepping in C source only steps by single machine instruction.
> >> I had expected that GDB might try to set breakpoints on the next
> >> instruction and then continue, but I see no such requests from GDB.
> >> How does GDB cause single steps through C (any high level language)
> >> source?
> >It does hardware single steps until the source line of the $pc changes.
> 
> Interesting.  It makes no requests to set breakpoints.  If I explicitly 
> set breakpoints, they work.   But when I issue the step command, I get 
> no breakpoint commands at my proxy application from GDB.  Any Ideas?

I have no idea what you mean; could you give a concrete example?

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: single-stepping remote target fails

[Ramana Radhakrishnan]

On Thu, 2005-06-23 at 11:40 -0400, Chad Phillips wrote:
>  >On Thu, Jun 23, 2005 at 11:18:28AM -0400, Chad Phillips wrote:
>  >> Problem 1.
>  >> Single stepping in C source only steps by single machine instruction.
>  >> I had expected that GDB might try to set breakpoints on the next
>  >> instruction and then continue, but I see no such requests from GDB.
>  >> How does GDB cause single steps through C (any high level language)
>  >> source?
>  >It does hardware single steps until the source line of the $pc changes.
> 
> Interesting.  It makes no requests to set breakpoints.  If I explicitly 
> set breakpoints, they work.   But when I issue the step command, I get 
> no breakpoint commands at my proxy application from GDB.  Any Ideas?

Can your stub single step by itself without the debugger ? Guess you can
do with the JTAG on. Does your remote stub support the single stepping
packet ? 

In any case do a set debug remote 1 just before you single step and
paste the output log over here. That could help answering.  

cheers
Ramana	



> 
>  >> Problem 2.
>  >> When I issue the step command (or si, n, ni) to the target, GDB does
>  >> a _lot_ of memory reads.  It reads from the start of main up to the
>  >> current PC (in main).  What is it doing, and how can I make it stop?
> 
>  >Preumably it is doing prologue analysis.  You need to work out (A) why
>  >it triggered the prolgoue analyzer and (B) whether you should be using
>  >unwind information instead of prologue analysis.
> 
> Thanks.  That make sense.
> 
> -Chad

Re: single-stepping remote target fails

[Chad Phillips]

Ramana,

The output log follows.
----------------------------------------------------------
(gdb) target remote localhost:1000
Remote debugging using localhost:1000
Sending packet: $Hc-1#09...Ack
Packet received:
Sending packet: $qC#b4...Ack
Packet received:
Sending packet: $qOffsets#4b...Ack
Packet received:
Sending packet: $?#3f...Ack
Packet received: S00
Sending packet: $Hg0#df...Ack
Packet received:
Sending packet: $p40#d4...Ack
Packet received: 0000438C
Sending packet: $p0#a0...Ack
Packet received: 00801D8C
main () at main.c:159
159         while(!PITFlag)
(gdb) s
Sending packet: $p1#a1...Ack
Packet received: 00C70000
Sending packet: $m4180,2#98...Ack
Packet received: 24F0
Sending packet: $m4182,2#9a...Ack
Packet received: 007D
Sending packet: $m4184,2#9c...Ack
Packet received: 6681
Sending packet: $m4186,2#9e...Ack
Packet received: 0510

...(memory reads from 0x4188 through 0x4384)...

Sending packet: $m4386,2#a0...Ack
Packet received: 97A0
Sending packet: $m4388,2#a2...Ack
Packet received: F7F0
Sending packet: $m438a,2#cb...Ack
Packet received: 7F5E
Sending packet: $vCont?#49...Ack
Packet received:
Packet vCont (verbose-resume) is NOT supported
Sending packet: $Hc0#db...Ack
Packet received:
Sending packet: $s#73...Ack
Packet received: S00
Sending packet: $p40#d4...Ack
Packet received: 0000438E

Program received signal 0, Signal 0.
Sending packet: $p0#a0...Ack
Packet received: 00801D8C
0x0000438e in main () at main.c:159
159         while(!PITFlag)
(gdb)

----------------------------------------------------------
GDB never sends a 'Z1' packet to set a hardware breakpoint as part of 
the step.

-Chad





Ramana Radhakrishnan wrote:
> On Thu, 2005-06-23 at 11:40 -0400, Chad Phillips wrote:
> 
>> >On Thu, Jun 23, 2005 at 11:18:28AM -0400, Chad Phillips wrote:
>> >> Problem 1.
>> >> Single stepping in C source only steps by single machine instruction.
>> >> I had expected that GDB might try to set breakpoints on the next
>> >> instruction and then continue, but I see no such requests from GDB.
>> >> How does GDB cause single steps through C (any high level language)
>> >> source?
>> >It does hardware single steps until the source line of the $pc changes.
>>
>>Interesting.  It makes no requests to set breakpoints.  If I explicitly 
>>set breakpoints, they work.   But when I issue the step command, I get 
>>no breakpoint commands at my proxy application from GDB.  Any Ideas?
> 
> 
> Can your stub single step by itself without the debugger ? Guess you can
> do with the JTAG on. Does your remote stub support the single stepping
> packet ? 
> 
> In any case do a set debug remote 1 just before you single step and
> paste the output log over here. That could help answering.  
> 
> cheers
> Ramana	
> 
> 
> 
> 
>> >> Problem 2.
>> >> When I issue the step command (or si, n, ni) to the target, GDB does
>> >> a _lot_ of memory reads.  It reads from the start of main up to the
>> >> current PC (in main).  What is it doing, and how can I make it stop?
>>
>> >Preumably it is doing prologue analysis.  You need to work out (A) why
>> >it triggered the prolgoue analyzer and (B) whether you should be using
>> >unwind information instead of prologue analysis.
>>
>>Thanks.  That make sense.
>>
>>-Chad
> 
> 
> 

Re: single-stepping remote target fails

[Daniel Jacobowitz]

On Thu, Jun 23, 2005 at 01:06:42PM -0400, Chad Phillips wrote:
> Sending packet: $s#73...Ack
> Packet received: S00
> Sending packet: $p40#d4...Ack
> Packet received: 0000438E
> 
> Program received signal 0, Signal 0.

You should be returning S05, SIGTRAP.

> GDB never sends a 'Z1' packet to set a hardware breakpoint as part of 
> the step.

Why should it?  Your stub claims to support hardware single step which
does not require a breakpoint.

-- 
Daniel Jacobowitz
CodeSourcery, LLC

Re: single-stepping remote target fails

[Chad Phillips]

> On Thu, Jun 23, 2005 at 01:06:42PM -0400, Chad Phillips wrote:
>> Sending packet: $s#73...Ack
>> Packet received: S00
>> Sending packet: $p40#d4...Ack
>> Packet received: 0000438E
>> 
>> Program received signal 0, Signal 0.
> 
> You should be returning S05, SIGTRAP.
> 

Fantastic!  That solved my problem.  Now, gdb continues to step to the 
next source instruction.  Thanks!

BTW, the documentation for the remote protocol simply says that the 
signal number is 'poorly defined', and in general to use UNIX 
conventions.  I made the incorrect assumption that the signal number is 
irrelevant.  Are there other signal numbers that have significance to GDB?

>> GDB never sends a 'Z1' packet to set a hardware breakpoint as part of 
>> the step.
> 
> Why should it?  Your stub claims to support hardware single step which
> does not require a breakpoint.

Got it.  I understand now.

Now I just have to figure out the prologue thing.
Thanks again.
-Chad

Re: single-stepping remote target fails

[Daniel Jacobowitz]

On Thu, Jun 23, 2005 at 04:37:32PM -0400, Chad Phillips wrote:
> 
> >On Thu, Jun 23, 2005 at 01:06:42PM -0400, Chad Phillips wrote:
> >>Sending packet: $s#73...Ack
> >>Packet received: S00
> >>Sending packet: $p40#d4...Ack
> >>Packet received: 0000438E
> >>
> >>Program received signal 0, Signal 0.
> >
> >You should be returning S05, SIGTRAP.
> >
> 
> Fantastic!  That solved my problem.  Now, gdb continues to step to the 
> next source instruction.  Thanks!
> 
> BTW, the documentation for the remote protocol simply says that the 
> signal number is 'poorly defined', and in general to use UNIX 
> conventions.  I made the incorrect assumption that the signal number is 
> irrelevant.  Are there other signal numbers that have significance to GDB?

I think, only cosmetically.

-- 
Daniel Jacobowitz
CodeSourcery, LLC