This is the mail archive of the ecos-discuss@sources.redhat.com mailing list for the eCos project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GDB stub for RAM startup (question again !!)


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]