Re: Remote stub for ARM processor

[Steven Johnson <sjohnson@neurizon.net>]

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