Re: Remote stub for ARM processor

["Modi Banti" <b dot modi at sssup dot 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)