This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
Re: Remote stub for ARM processor
- From: Steven Johnson <sjohnson at neurizon dot net>
- To: Modi Banti <b dot modi at sssup dot it>
- Cc: gdb at sources dot redhat dot com
- Date: Mon, 28 Jun 2004 09:50:37 +1000
- Subject: Re: Remote stub for ARM processor
- References: <web-4609543@sssup.it>
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