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