[ECOS] Problems with GDB on MPC8240

[ECOS] Problems with GDB on MPC8240

[K Srinivas Aithal]

Hi,

We are facing a lot of problems with bringing up gdb. We have already
brought up RedBoot. I'm able to connect to the target through gdb. I'm
also able to load the program. Once I give the "continue" I'm struck;
even if I give a breakpoint. I'm testing withj the Hello application.



The follwing is the snapshot of what is happening at the FRIST TIME
after boot of my linux (RH6.2) host
(gdb) load
Loading section .text, size 0x138e4 lma 0xf6000
Loading section .rodata, size 0x858 lma 0x1098e8
Loading section .data, size 0x704 lma 0x10a140
Start address 0xf6000 , load size 84032
Transfer rate: 26890 bits/sec, 506 bytes/write.
(gdb) set debug remote 1
(gdb) break cyg_user_start
Sending packet: $mf6544,4#06...Ack
Packet received: 4082102c
Breakpoint 1 at 0xf6544: file hello.c, line 13.
(gdb) continue
Continuing.
Sending packet: $Z0,f6544,4#4f...Ack
Packet received: OK
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $c#63...Ack
Packet received: T0f40:50494338;01:000030a3;

Program received signal SIGTERM, Terminated.
Sending packet: $z0,f6544,4#6f...Ack
Packet received: OK
0x50494338 in ?? ()





The follwing is the snapshot of what is happening for all OTHER tries
after boot of my linux (RH6.2) host
(gdb) set remotebaud 38400
(gdb) target remote /dev/ttyS0
Remote debugging using /dev/ttyS0
0xa6358 in ?? ()
(gdb) load
Loading section .text, size 0x138e4 lma 0xf6000
Loading section .rodata, size 0x858 lma 0x1098e8
Loading section .data, size 0x704 lma 0x10a140
Start address 0xf6000 , load size 84032
Transfer rate: 26890 bits/sec, 506 bytes/write.
(gdb)
(gdb) set debug remote 1
(gdb) del 1
(gdb) b cyg_user_start
Sending packet: $mf6544,4#06...Ack
Packet received: 4082102c
Breakpoint 2 at 0xf6544: file hello.c, line 13.
(gdb) continue
Continuing.
Sending packet: $Z0,f6544,4#4f...Ack
Packet received: OK
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $c#63...Ack
(gdb) continue
Continuing.
Sending packet: $Z0,f6544,4#4f...Ack
Packet received: OK
Sending packet: $Hc0#db...Ack
Packet received: OK
Sending packet: $c#63...Ack


I donot understand why the program is getting the SIGTERM ONLY for the
first time.


Also, I found that when I give the "continue" command at the gdb
console prompt, the RedBoot is able to return in the sequence of
functions  __handle_exception(), cyg_hal_exception_handler(),
cyg_default_exception_handler(). I have yet to trace if it is restoring
the state propoerly now.  


I hope it is not required to port any extra debugging stuffs in the
powerpc HAL (this is because it is already there for PPC603 simulator
version and MPC8240's core is PPC603). I have enabled the
"...BREAKPOINT_LIST_SIZE..." macro;but still it is the same; is this
really required. I donot know where am I doing the mistake.


The flash of my board has DINK32 running on it. I'm running the RAM
version of RedBoot on DINK32. My "Hello application" is linked to the
memory area which is flagged free by the RedBoot. Could there a clash
between the exception handlers of the DINK and eCos.


I didn't get any help for some of my previous mails on this discuss
list. Please help us to start debugging my applications.



Thanks and Regards,
K Srinivas Aithal

 



__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Re: [ECOS] Problems with GDB on MPC8240

[Jesper Skov]

>>>>> "K" == K Srinivas Aithal <ksaithal_ecos@yahoo.com> writes:

K> Hi, We are facing a lot of problems with bringing up gdb. We have
K> already brought up RedBoot. I'm able to connect to the target
K> through gdb. I'm also able to load the program. Once I give the
K> "continue" I'm struck; even if I give a breakpoint. I'm testing
K> withj the Hello application.

So instead of setting a breakpoint + continue, try to single
(instruction) step your way through the Hellow World
application. Nothing in the logs you posted suggests a RedBoot/stubs
problem - it might as well be the application doing silly things.

Jesper

Re: [ECOS] Problems with GDB on MPC8240

[K Srinivas Aithal]

Hi Jesper,

Thanks for that. We found that the instruction we expected is not
really there in the memory. The problem is solved now. There was a
small mistake in the porting of the call
"cyg_hal_plf_serial_getc_nonblock()" call. We were missing out the char
'0' on reception; so the program was not getting downloaded properly. 

I do have still more problems. The program is not stopping at the given
breakpoint. Do I need to port any extra stubs for my platform. But I
saw the that the 603 pased simulator works fine in this regard; so I
think even MPC8240 based board should work the same. Or does
the "target sim" at the (gdb) prompt of "powerpc-eabi-gdb" will take
care of this. Should I port the InstructionBreak exception of 8240 also
for this.

I have one more doubt. My sample application is a hello program (which
I took it from the eCos example secion). I'm expecting "Hello" at the
gdb   console; but I'm not getting it. The reason for this is 
incorrect serial device base address specified in the serial driver at
"packages/devs/serial". My doubt is "Can the serial driver within hello
application pack the string ..hello.. as required by the gdb protocol
so that the gdb console can understand" Or "if it donot can the gdb
console print it on the host properly". 


Thanks and Regards,
K Srinivas Aithal


--- Jesper Skov <jskov@redhat.com> wrote:
> >>>>> "K" == K Srinivas Aithal <ksaithal_ecos@yahoo.com> writes:
> 
> K> Hi, We are facing a lot of problems with bringing up gdb. We have
> K> already brought up RedBoot. I'm able to connect to the target
> K> through gdb. I'm also able to load the program. Once I give the
> K> "continue" I'm struck; even if I give a breakpoint. I'm testing
> K> withj the Hello application.
> 
> So instead of setting a breakpoint + continue, try to single
> (instruction) step your way through the Hellow World
> application. Nothing in the logs you posted suggests a RedBoot/stubs
> problem - it might as well be the application doing silly things.
> 
> Jesper


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/

Re: [ECOS] Problems with GDB on MPC8240

[Jesper Skov]

>>>>> "K" == K Srinivas Aithal <ksaithal_ecos@yahoo.com> writes:

K> I do have still more problems. The program is not stopping at the
K> given breakpoint. Do I need to port any extra stubs for my
K> platform. But I saw the that the 603 pased simulator works fine in
K> this regard; so I think even MPC8240 based board should work the
K> same. Or does the "target sim" at the (gdb) prompt of
K> "powerpc-eabi-gdb" will take care of this. Should I port the
K> InstructionBreak exception of 8240 also for this.

The sim does not rely on stub support, so the stubs are untested on a
603. In any event, GDB is the one setting breakpoints, so all I can
think of causing the problem would be the cache. Try disabling it.

K> I have one more doubt. My sample application is a hello program
K> (which I took it from the eCos example secion). I'm expecting
K> "Hello" at the gdb console; but I'm not getting it. The reason for
K> this is incorrect serial device base address specified in the
K> serial driver at "packages/devs/serial". My doubt is "Can the
K> serial driver within hello application pack the string ..hello.. as
K> required by the gdb protocol so that the gdb console can
K> understand" Or "if it donot can the gdb console print it on the
K> host properly".

The hello world example uses printf() which (in the default
configuration) layers on the HAL diag functions. These will do the
necessary encoding for GDB.

Jesper

Re: [ECOS] Problems with GDB on MPC8240

[K Srinivas Aithal]

Hi Jesper,

I had specified "CYGNUM_HAL_BREAKPOINT_LIST_SIZE" as 10. Now I have
disabled it. It does break and step now. But still the problem exists.

Single step (i have checked "si") works fine if I just continue doing
only that!

Now if I give a breakpoint and "continue" it does stop at that
breakpoint. But it gets struck there. If I give a continue now (or even
"si") the program loops around at the same breakpoint. I changed the
value of PC (and set the values of register at PC where it had stopped)
and continued my program ends safely (ofcourse again printf() is not
printing "Hello" at the gdb console). Even if I delete the old
breakpoint and set a new one it will halt at the same old breakpoint;
but gdb console is infact setting the breakInstrcution at the new
breakpoint I specify!. This i observed that the "send_t_packet()" is
still sending the information about the old breakpoint!. As suggested
by you I disabled the cache; but it is the same.  

I analyzed the code and found that the break works on s/w breakpoints.
The gdb console is setting the breakInstruction at the the specified
breakpoint location. Once the 8240 looks that breakInstruction, it
enters the exception state, it is getting filed with the actual
instruction when the gdb console recevies the "T" packet from the stub.
It is getting struck after this; even "si" donot work. Where could the
stub going wrong. Do I need to port anything extra for this. 

I'm working on the CVS eCos.  

Regards,
K Srinivas Aithal

--- Jesper Skov <jskov@redhat.com> wrote:
> >>>>> "K" == K Srinivas Aithal <ksaithal_ecos@yahoo.com> writes:
> 
> K> I do have still more problems. The program is not stopping at the
> K> given breakpoint. Do I need to port any extra stubs for my
> K> platform. But I saw the that the 603 pased simulator works fine in
> K> this regard; so I think even MPC8240 based board should work the
> K> same. Or does the "target sim" at the (gdb) prompt of
> K> "powerpc-eabi-gdb" will take care of this. Should I port the
> K> InstructionBreak exception of 8240 also for this.
> 
> The sim does not rely on stub support, so the stubs are untested on a
> 603. In any event, GDB is the one setting breakpoints, so all I can
> think of causing the problem would be the cache. Try disabling it.
> 
> K> I have one more doubt. My sample application is a hello program
> K> (which I took it from the eCos example secion). I'm expecting
> K> "Hello" at the gdb console; but I'm not getting it. The reason for
> K> this is incorrect serial device base address specified in the
> K> serial driver at "packages/devs/serial". My doubt is "Can the
> K> serial driver within hello application pack the string ..hello..
> as
> K> required by the gdb protocol so that the gdb console can
> K> understand" Or "if it donot can the gdb console print it on the
> K> host properly".
> 
> The hello world example uses printf() which (in the default
> configuration) layers on the HAL diag functions. These will do the
> necessary encoding for GDB.
> 
> Jesper


__________________________________________________
Do You Yahoo!?
Make international calls for as low as $.04/minute with Yahoo! Messenger
http://phonecard.yahoo.com/