* Remote stub for ARM processor
@ 2004-06-27 2:26 Modi Banti
2004-06-27 23:50 ` Steven Johnson
2004-07-10 16:11 ` How does GDB informs remote stub about '^Cremote_interrupt called ' Modi Banti
0 siblings, 2 replies; 5+ messages in thread
From: Modi Banti @ 2004-06-27 2:26 UTC (permalink / raw)
To: gdb
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.
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?
Thanks and regards,
Banti
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Remote stub for ARM processor
2004-06-27 2:26 Remote stub for ARM processor Modi Banti
@ 2004-06-27 23:50 ` Steven Johnson
2004-06-28 14:03 ` Modi Banti
2004-07-10 16:11 ` How does GDB informs remote stub about '^Cremote_interrupt called ' Modi Banti
1 sibling, 1 reply; 5+ messages in thread
From: Steven Johnson @ 2004-06-27 23:50 UTC (permalink / raw)
To: Modi Banti; +Cc: gdb
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
>
>
>
>
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Remote stub for ARM processor
2004-06-27 23:50 ` Steven Johnson
@ 2004-06-28 14:03 ` Modi Banti
0 siblings, 0 replies; 5+ messages in thread
From: Modi Banti @ 2004-06-28 14:03 UTC (permalink / raw)
To: Steven Johnson; +Cc: gdb
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)
^ permalink raw reply [flat|nested] 5+ messages in thread
* How does GDB informs remote stub about '^Cremote_interrupt called '
2004-06-27 2:26 Remote stub for ARM processor Modi Banti
2004-06-27 23:50 ` Steven Johnson
@ 2004-07-10 16:11 ` Modi Banti
2004-07-11 5:32 ` Alexander Stante
1 sibling, 1 reply; 5+ messages in thread
From: Modi Banti @ 2004-07-10 16:11 UTC (permalink / raw)
To: gdb
I am building a remote stub for an Arm simulator. I am
using sockets to communicate with GDB. when I want to
break my program using through GDB( C -c) I cann see the
message ' ^Cremote_interrupt called' in GDB but I dont get
any packets in my reomte stub. I am not sure how GDB
informs the remote target to stop? does anybody have any
idea about this?
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: How does GDB informs remote stub about '^Cremote_interrupt called '
2004-07-10 16:11 ` How does GDB informs remote stub about '^Cremote_interrupt called ' Modi Banti
@ 2004-07-11 5:32 ` Alexander Stante
0 siblings, 0 replies; 5+ messages in thread
From: Alexander Stante @ 2004-07-11 5:32 UTC (permalink / raw)
To: Modi Banti; +Cc: gdb
Modi Banti wrote:
> I am building a remote stub for an Arm simulator. I am using sockets to
> communicate with GDB. when I want to break my program using through GDB(
> C -c) I cann see the message ' ^Cremote_interrupt called' in GDB but I
> dont get any packets in my reomte stub. I am not sure how GDB informs
> the remote target to stop? does anybody have any idea about this?
I added a GdbStub for a game console emulator on which the actual code
for debugging is running on. But instead of sockets I used pipe to
communicate. In this case gdb just sends a ^C to the emulator which
leads to a SIGINT signal. I just had to wrote a SIGINT handler for the
emulator to get this working correctly. The handler just sets a Variable
to '1' and the Emulator checks at a certain point. If it is sets and
handels control over to the "main" function of the stub where all the
command processing is done. Not exactly the case you have but maybe that
helps.
Bye
Alex
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2004-07-11 5:32 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2004-06-27 2:26 Remote stub for ARM processor Modi Banti
2004-06-27 23:50 ` Steven Johnson
2004-06-28 14:03 ` Modi Banti
2004-07-10 16:11 ` How does GDB informs remote stub about '^Cremote_interrupt called ' Modi Banti
2004-07-11 5:32 ` Alexander Stante
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).