[ECOS] GDB stub for RAM startup (question again !!)

[Jonathan Larmour]

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