Re: Remote stub for ARM processor

["Modi Banti" <b.modi@sssup.it>]

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)