This is the mail archive of the
ecos-discuss@sources.redhat.com
mailing list for the eCos project.
Re: GDB stub for RAM startup (question again !!)
- From: Jonathan Larmour <jifl at eCosCentric dot com>
- To: Ottawa Guy <ottawaguy81 at yahoo dot com>
- Cc: ecos-discuss at ecos dot sourceware dot org
- Date: Sat, 14 Feb 2004 06:09:53 +0000
- Subject: Re: [ECOS] GDB stub for RAM startup (question again !!)
- References: <20040213020407.48778.qmail@web60904.mail.yahoo.com>
Ottawa Guy wrote:
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.
That's true for normal breakpoints, but not for single stepping. Although I
guess if perhaps a stub said it didn't support the single step packet, GDB
would fall back to that mode. Instead eCos assumes single stepping will be
supported in HALs because the overhead of single stepping by steam like
that is dreadfully slow.
In some platform I saw people implementing single step
in software [ __single_step() function]. Why ??
Not some. All :-). All architectures support __single_step.
Question 2
++++++++++++
Since GDB client keeps the breakpoint list, why is the
function __clear_breakpoint_list() exist in ECOS.
That's for Z packet-style breakpoint support, which eCos does support. In
that case GDB doesn't read/write breakpoints into memory but lets eCos
handle it. Z packets are lower overhead to use and more compatible with
hardware debugging.
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
I haven't looked in detail (no time for detailed stuff like that for
non-customers, sorry), but T packets aren't just thread info, but indicate
when targets have hit an exception and passed back into the stub, e.g. due
to a bug. The T packet contains the PC address of the problem instruction,
so find where that is.
Jifl
--
eCosCentric http://www.eCosCentric.com/ The eCos and RedBoot experts
Visit us at Embedded World 2004, Nürnberg, Germany, 17-19 Feb, Stand 12-449
--["No sense being pessimistic, it wouldn't work anyway"]-- Opinions==mine
--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss