This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
GDB stub for RAM startup (question again !!)
- From: Ottawa Guy <ottawaguy81 at yahoo dot com>
- To: ecos-discuss at ecos dot sourceware dot org
- Date: Thu, 12 Feb 2004 18:04:07 -0800 (PST)
- Subject: [ECOS] GDB stub for RAM startup (question again !!)
Hello everyone,
Thank you all for your reponses. My ECOS GDB stub is
almost working. I have few GDB question.
Qestion 1
++++++++++
When the target doesnt have H/W support for single
step, I am assuming the GDB client(HOST) software
takes care of single step functinality. I am
assuming gdb client software sets a trap instruction
at NPC and sends a continue MSG to gdb stubs(target).
And later gdb client software (HOST) would put the
original instruction back at that address.
In some platform I saw people implementing single step
in software [ __single_step() function]. Why ??
Question 2
++++++++++++
Since GDB client keeps the breakpoint list, why is the
function __clear_breakpoint_list() exist in ECOS.
Question 3
+++++++++++
I have a simple hello.c file which looks like
main ()
{
breakpoint();
printf("hello world");
}
As you can see when I start my program it jumps to gdb
stub . I can enquire about threads, register , etc.
Through GDB client(host) I could send "continue"
instruciton and it would successfully excute my
program. However if I put a break point at "printf"
and continue, my GDB stubs seems to act wierd. Even my
"singles" instruction doesnt work properly.
Can some one have a look at it, and let me know whats
happening there. Following is my output
(gdb) set debug remote 1
(gdb) bre *0x100132c // break at printf
Breakpoint 1 at 0x100132c: file hello.c, line 12.
(gdb) c
Continuing.
Sending packet: $Z0,100132c,4#a0...Ack
Packet received:
Packet Z0 (software-breakpoint) is NOT supported
Sending packet: $m100132c,4#57...Ack
Packet received: 13004070
Sending packet: $X100132c,0:#78...Ack
Packet received: OK
binary downloading suppported by target
Sending packet: $X100132c,4:\221%G�%@
\001#fe...Ack
Packet received: OK
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $C10#a4...Ack
Packet received:
T10thread:00000002;44:0100132c;0e:01021610;
[New Thread 2]
Sending packet: $C10#a4...Ack
Packet received:
T10thread:00000002;44:0100132c;0e:01021610;
Sending packet: $C10#a4...Ack
Sending packet: $C10#a4...Ack
Packet received:
T10thread:00000002;44:0100132c;0e:01021610;
Sending packet: $C10#a4...Ack
Sending packet: $C10#a4...Ack
Packet received:
T10thread:00000002;44:0100132c;0e:01021610;
Sending packet: $C10#a4...Ack
Packet received:
T10thread:00000002;44:0100132c;0e:01021610;
Sending packet: $C10#a4...Ack
Packet received:
T10thread:00000002;44:0100132c;0e:01021610;
++++++++++++++++++++++++++++++++++++++++++++++++++
As you can see the GDB stub keeps on reponding with
thread information. What the GDB stub suppose to
response after "$C10#a4" command from the GDB client
(HOST). OBJDUMP of my hello.c is following
++++++++++++++++++++++++++++++
int main ()
{
1001310: 9d e3 bf 90 save %sp, -112, %sp
int p =5;
1001314: 90 10 20 05 mov 5, %o0
1001318: d0 27 bf f4 st %o0, [ %fp + -12 ]
breakpoint();
100131c: 40 00 18 b7 call 10075f8
<breakpoint>
1001320: 01 00 00 00 nop
p=10;
1001324: 90 10 20 0a mov 0xa, %o0 ! a
<*ABS*+0xa>
1001328: d0 27 bf f4 st %o0, [ %fp + -12 ]
printf ("Hello world \n");
100132c: 13 00 40 70 sethi %hi(0x101c000),
%o1
1001330: 90 12 62 08 or %o1, 0x208, %o0
! 101c208 <_etext+0x8>
1001334: 40 00 36 8b call 100ed60 <printf>
1001338: 01 00 00 00
Thanks in advance
Ottawa
__________________________________
Do you Yahoo!?
Yahoo! Finance: Get your refund fast by filing online.
http://taxes.yahoo.com/filing.html
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss