Remote stub for ARM processor

Remote stub for ARM processor

[Modi Banti]

Hi,

I am trying to buikd a remote stub for an ARM processor 
Simulator. I have couple of problems with this...

1) When a Simulator arrives at a breakpoint it sends the 
signal SIGTRAP 15 (register number): PC to GDB so the GDB 
stops and shows the instruction at PC but since for ARM 
processor PC point to current instruction + 8, so it shows 
me a wrong line. I am not sure while displaying the line 
GDB takes into account of Pipiline. I can overcome this 
problem tempararily by sending the signal SIGTRAP 15: PC- 
8. so it works correctly but I am not sure if this is the 
correct way of doing it.

2) In reply to GDBs $s#73 (single step) command i send the 
same packet i.e SIGTRAP 15: PC - 8 . I am not sure if I 
need to send SIGTRAP or some other signal. Here also the 
'n' command works prefectly fine with normal code but if 
it is a Function call then instead of stopping at next 
line GDB stops at line after that 
  e. g for following code 
        Mutex_lock(&mut);
        ++i;
        ++j;
  if I give 'n' command when GDB is at Mutex_lock(&mut) 
then it gives some series of $s#73 commands and finaly 
stops at ++j instead of stopping at ++i. this happens only 
in case of function call for normal statements it works 
perfectly fine. Here I am not sure whether SIGTRAP is a 
right signal and secondly sending PC -15 is correct or not 
( if i send just PC here then insted og going to next 
instruction GDB steps in the function call). 

Can anybody help me with this or tell me which part of 
code in GDB handles this step instruction?

Thanks and regards,
Banti  


  

Re: Remote stub for ARM processor

[Steven Johnson]

Modi Banti wrote:

> Hi,
>
> I am trying to buikd a remote stub for an ARM processor Simulator. I 
> have couple of problems with this...
>
> 1) When a Simulator arrives at a breakpoint it sends the signal 
> SIGTRAP 15 (register number): PC to GDB so the GDB stops and shows the 
> instruction at PC but since for ARM processor PC point to current 
> instruction + 8, so it shows me a wrong line. I am not sure while 
> displaying the line GDB takes into account of Pipiline. I can overcome 
> this problem tempararily by sending the signal SIGTRAP 15: PC- 8. so 
> it works correctly but I am not sure if this is the correct way of 
> doing it.

You have this problem with a simulator or the real ARM.  I believe you
have to adjust the PC, to point to the actual line currently being
executed.  I am not aware of any pipeline awareness in GDB.  This is a
particular quirk of the ARM, and is made worse by Interrupts, where the
LR can have various offsets from the real return address, depending on
the IRQ/branch/Arm/thumb mode in question.  So trying to find where you
came from can be problematic (not sure how GDB resolves this when it
does a stack trace?)

EG, LR after a BL = PC+4 in ARM, and PC+2 in thumb.  but FIQ LR = PC+4
in both ARM and THUMB, but DABT LR = PC+8 for arm and thumb.  I believe
its up to the stub/simulator to deal with this quirk and any problems it
might cause GDB's knowledge of the executing program, by adjusting
accordingly.

>
> 2) In reply to GDBs $s#73 (single step) command i send the same packet 
> i.e SIGTRAP 15: PC - 8 . I am not sure if I need to send SIGTRAP or 
> some other signal. Here also the 'n' command works prefectly fine with 
> normal code but if it is a Function call then instead of stopping at 
> next line GDB stops at line after that  e. g for following code        
> Mutex_lock(&mut);
>        ++i;
>        ++j;
>  if I give 'n' command when GDB is at Mutex_lock(&mut) then it gives 
> some series of $s#73 commands and finaly stops at ++j instead of 
> stopping at ++i. this happens only in case of function call for normal 
> statements it works perfectly fine. Here I am not sure whether SIGTRAP 
> is a right signal and secondly sending PC -15 is correct or not ( if i 
> send just PC here then insted og going to next instruction GDB steps 
> in the function call).
> Can anybody help me with this or tell me which part of code in GDB 
> handles this step instruction?

n wont stop on the function call.  It should stop on the ++i; the GDB
manual says about "next":
   "This is similar to `step', but function calls that appear
     within the line of code are executed without stopping.  Execution
     stops when control reaches a different line of code at the
     original stack level that was executing when you gave the `next'
     command."

Im pretty sure the signal you send matters not in the reply.

Im sure you meant PC-8??  Maybe this has something to do with LR?
because a function call will use LR?  Maybe you need to "adjust" LR as
well, depending on circumstances, otherwise LR wont point to the ++i; it
will point to the ++j; (potentially confusing GDB if it uses it).

Sorry I cant be more helpful or categoric, we (my company) are in the
process of writing a GDB target stub for ARM, id be interested to know
how you fare with this problem.

Steven

>
> Thanks and regards,
> Banti 
>
>  
>
>

Re: Remote stub for ARM processor

[Modi Banti]

On Mon, 28 Jun 2004 09:50:37 +1000
  Steven Johnson <sjohnson@neurizon.net> wrote:
>Modi Banti wrote:
>
>> Hi,
>>
>> I am trying to buikd a remote stub for an ARM processor 
>>Simulator. I 
>> have couple of problems with this...
>>
>> 1) When a Simulator arrives at a breakpoint it sends the 
>>signal 
>> SIGTRAP 15 (register number): PC to GDB so the GDB stops 
>>and shows the 
>> instruction at PC but since for ARM processor PC point 
>>to current 
>> instruction + 8, so it shows me a wrong line. I am not 
>>sure while 
>> displaying the line GDB takes into account of Pipiline. 
>>I can overcome 
>> this problem tempararily by sending the signal SIGTRAP 
>>15: PC- 8. so 
>> it works correctly but I am not sure if this is the 
>>correct way of 
>> doing it.
>
>You have this problem with a simulator or the real ARM. 
> I believe you
>have to adjust the PC, to point to the actual line 
>currently being
>executed.  I am not aware of any pipeline awareness in 
>GDB.  This is a
>particular quirk of the ARM, and is made worse by 
>Interrupts, where the
>LR can have various offsets from the real return address, 
>depending on
>the IRQ/branch/Arm/thumb mode in question.  So trying to 
>find where you
>came from can be problematic (not sure how GDB resolves 
>this when it
>does a stack trace?)
>
>EG, LR after a BL = PC+4 in ARM, and PC+2 in thumb.  but 
>FIQ LR = PC+4
>in both ARM and THUMB, but DABT LR = PC+8 for arm and 
>thumb.  I believe
>its up to the stub/simulator to deal with this quirk and 
>any problems it
>might cause GDB's knowledge of the executing program, by 
>adjusting
>accordingly.
>
>>
>> 2) In reply to GDBs $s#73 (single step) command i send 
>>the same packet 
>> i.e SIGTRAP 15: PC - 8 . I am not sure if I need to send 
>>SIGTRAP or 
>> some other signal. Here also the 'n' command works 
>>prefectly fine with 
>> normal code but if it is a Function call then instead of 
>>stopping at 
>> next line GDB stops at line after that  e. g for 
>>following code        
>> Mutex_lock(&mut);
>>        ++i;
>>        ++j;
>>  if I give 'n' command when GDB is at Mutex_lock(&mut) 
>>then it gives 
>> some series of $s#73 commands and finaly stops at ++j 
>>instead of 
>> stopping at ++i. this happens only in case of function 
>>call for normal 
>> statements it works perfectly fine. Here I am not sure 
>>whether SIGTRAP 
>> is a right signal and secondly sending PC -15 is correct 
>>or not ( if i 
>> send just PC here then insted og going to next 
>>instruction GDB steps 
>> in the function call).
>> Can anybody help me with this or tell me which part of 
>>code in GDB 
>> handles this step instruction?
>
>n wont stop on the function call.  It should stop on the 
>++i; the GDB
>manual says about "next":
>   "This is similar to `step', but function calls that 
>appear
>     within the line of code are executed without 
>stopping.  Execution
>     stops when control reaches a different line of code 
>at the
>     original stack level that was executing when you 
>gave the `next'
>     command."
>
>Im pretty sure the signal you send matters not in the 
>reply.
>
>Im sure you meant PC-8??  Maybe this has something to do 
>with LR?
>because a function call will use LR?  Maybe you need to 
>"adjust" LR as
>well, depending on circumstances, otherwise LR wont point 
>to the ++i; it
>will point to the ++j; (potentially confusing GDB if it 
>uses it).
>
>Sorry I cant be more helpful or categoric, we (my 
>company) are in the
>process of writing a GDB target stub for ARM, id be 
>interested to know
>how you fare with this problem.
>
>Steven

Ok I got it working.....problem was GDB used to set a 
break point at next instruction after the function call 
and when stub informs GDB about break point it used to 
again issue $g# command and after looking at the contents 
of PC ( which was actual PC )it used to decide not to 
stop.... so here I always send PC - 8 ( depending on mode) 
and everything works correctly only drawback is when I say 
' info Registers' instead of seeing the correct PC i see 
the adjusted PC ( I guess I have to live with it)

How does GDB informs remote stub about '^Cremote_interrupt called '

[Modi Banti]

I am building a remote stub for an Arm simulator. I am 
using sockets to communicate with GDB. when I want to 
break my program using through GDB( C -c) I cann see the 
message ' ^Cremote_interrupt called' in GDB but I dont get 
any packets in my reomte stub. I am not sure how GDB 
informs the remote target to stop? does anybody have any 
idea about this?

Re: How does GDB informs remote stub about '^Cremote_interrupt called '

[Alexander Stante]

Modi Banti wrote:
> I am building a remote stub for an Arm simulator. I am using sockets to 
> communicate with GDB. when I want to break my program using through GDB( 
> C -c) I cann see the message ' ^Cremote_interrupt called' in GDB but I 
> dont get any packets in my reomte stub. I am not sure how GDB informs 
> the remote target to stop? does anybody have any idea about this?

I added a GdbStub for a game console emulator on which the actual code 
for debugging is running on. But instead of sockets I used pipe to 
communicate. In this case gdb just sends a ^C to the emulator which 
leads to a SIGINT signal. I just had to wrote a SIGINT handler for the 
emulator to get this working correctly. The handler just sets a Variable 
to '1' and the Emulator checks at a certain point. If it is sets and 
handels control over to the "main" function of the stub where all the 
command processing is done. Not exactly the case you have but maybe that 
helps.

Bye
Alex