[prev in list] [next in list] [prev in thread] [next in thread]
List: gdb
Subject: Re: Remote stub for ARM processor
From: "Modi Banti" <b.modi () sssup ! it>
Date: 2004-06-28 8:39:25
Message-ID: web-4622147 () sssup ! it
[Download RAW message or body]
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)
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic