[ECOS] GDB Issue on MPC837X

Chris Cuthbert nd6969@hotmail.com
Fri Mar 11 16:04:00 GMT 2011


What I do is as follows:
Redboot>load -r -v -d -b 0x100000 100GMUxApp.slim
Redboot>go 0x100000

This works fine. Now, if I don't say 'go 0x100000' and log out of the debug port, then run gdb and do 'tar rem' and then say 'jump *0x100000' I get into this cycle of exceptions.

I can see that the GDB registers have the PC set to 0x100000, but for some reason after gdb client sends the 'c' command to the target and target tries to return from the exception, it gets another exception when it does 'isync' just before 'rfi'.

Going thru the stub code, I can't figure out where exactly the stub code is supposed to switch from gdb to the program at location 0x100000.

Thanx.

----------------------------------------
> Date: Tue, 8 Mar 2011 10:57:51 -0700
> From: gary@mlbassoc.com
> To: nd6969@hotmail.com
> CC: ccoutand@stmi.com; ecos-discuss@ecos.sourceware.org
> Subject: Re: [ECOS] GDB Issue on MPC837X
>
> On 03/08/11 10:47, Chris Cuthbert wrote:
> >
> > Forgot the RAM dump. Yes, there is no issue with RAM initialization because I can run the application from redboot prompt.
> >
> > RedBoot> x -b 0x100000 -l 0x100 -4
> > 00100000: 3C600010 60630010 7C6803A6 4E800020
> > 00100010: 3C400059 604240F4 7C631A78 7C7C43A6
> > 00100020: 7C842278 7C9D43A6 48264035 3C200059
> > 00100030: 60214D70 7C3043A6 3C600010 606301C4
> > 00100040: 3C800000 60843000 90640014 90640024
> > 00100050: 90640028 90640038 3C600058 6063D070
> > 00100060: 3C800061 60842B20 38000000 7C032040
> > 00100070: 4182001C 7C832050 5484F0BE 7C8903A6
> > 00100080: 3863FFFC 94030004 4200FFFC 3C600058
> > 00100090: 6063C110 3C800058 6084D064 7C032040
> > 001000A0: 4182001C 7C832050 5484F0BE 7C8903A6
> > 001000B0: 3863FFFC 94030004 4200FFFC 3821FFF4
> > 001000C0: 38000000 90010000 90010008 9421FFC8
> > 001000D0: 48263A05 48263E85 482633E5 3C600000
> > 001000E0: 60633032 7C0004AC 7C600124 7C0004AC
> > 001000F0: 482634D9 48263785 48263161 4823A759
> > RedBoot>
>
> Does the program actually start execution at 0x100000? Binaries on PowerPC
> will typically start at something like 0x100100. When you load the program
> via RedBoot, it figures this out and the 'go' command jumps to the right
> place.
>
> Also, you could try loading the program via GDB, e.g.
> (gdb) tar rem XXX
> (gdb) lo .elf
> (gdb) go
>
> >
> > ----------------------------------------
> >> Subject: RE: [ECOS] GDB Issue on MPC837X
> >> Date: Tue, 8 Mar 2011 06:01:18 -0800
> >> From: ccoutand@stmi.com
> >> To: nd6969@hotmail.com; ecos-discuss@ecos.sourceware.org
> >>
> >> Hi,
> >>
> >> How do you load the application in RAM? Are you building a ROMRAM type of application that relocates to RAM which you plan to debug using the GDB stubs? Can you dump the memory content at address 0x100000 and forward, is the memory initialized?
> >>
> >> Christophe
> >>
> >> -----Original Message-----
> >> From: ecos-discuss-owner@ecos.sourceware.org [mailto:ecos-discuss-owner@ecos.sourceware.org] On Behalf Of Chris Cuthbert
> >> Sent: 8. mars 2011 02:33
> >> To: ecos-discuss
> >> Subject: [ECOS] GDB Issue on MPC837X
> >>
> >>
> >> Hello,
> >>
> >> I am trying to get gdb working on a MPC847X ERDB eval board using the serial port.
> >> Basically, I cannot get gdb to start executing the application loaded in RAM at 0x100000.
> >> Logs below.
> >>
> >> Any help appreciated.
> >> Thanx.
> >>
> >> =~=~=~=~=~=~=~=~=~=~=~= PuTTY log 2011.03.07 15:42:06 =~=~=~=~=~=~=~=~=~=~=~=
> >> (gdb) set debug serial 10
> >> (gdb) set debug remote 1
> >> (gdb) tar rem /dev/ttySI166
> >> Remote debugging using /dev/ttySI166
> >> Sending packet: $Hc-1#09...[
> >> r +]Ack
> >> [$][O][K][#][9][a]Packet received: OK
> >> Sending packet: $qC#b4...[+]Ack
> >> [$][E][0][2][#][a][7]Packet received: E02
> >> Sending packet: $qOffsets#4b...[+]Ack
> >> [$][#][0][0]Packet received:
> >> Sending packet: $?#3f...[+]Ack
> >> [$][S][0][4][#][b][7]Packet received: S04
> >> Sending packet: $Hg0#df...[+]Ack
> >> [$][O][K][#][9][a]Packet received: OK
> >> Sending packet: $g#67...[+]Ack
> >> [$][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0]
> [0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0]
> [0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][0][#][8][0]Packet received: 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> 0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000
> >> 0x0 in __lshrdi3 (u=0, b=0)
> >> (gdb)
> >> (gdb) jump *0x100000
> >> Line 16 is not in `__lshrdi3'. Jump anyway? (y or n) y
> >> Continuing at 0x100000.
> >> Sending packet: $P40=00100000#72...[+]Ack
> >> [$][O][K][#][9][a]Packet received: OK
> >> Sending packet: $Hc0#db...[+]Ack
> >> [$][O][K][#][9][a]Packet received: OK
> >> Sending packet: $c#63...[+]Ack
> >> [$][T][0][4][4][0][:][0][0][1][0][0][0][0][0][;][0][1][:][0][0][0][0][0][0][0][0][;][#][6][8]Packet received: T0440:00100000;01:00000000;
> >>
> >> Program received signal SIGILL, Illegal instruction.
> >> 0x100000 in _stext () at include/exception:16
> >> 16 virtual ~exception () { }
> >> Current language: auto; currently c++
> >> (gdb)
> >>
> >>
> >>
> >> --
> >> Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
> >> and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss
> >>
> >
> >
>
> --
> ------------------------------------------------------------
> Gary Thomas | Consulting for the
> MLB Associates | Embedded world
> ------------------------------------------------------------
 		 	   		  

--
Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos
and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss



More information about the Ecos-discuss mailing list