Is it possible to use Eclipse with CodeSourcery G++ Lite for
simulation-type debugging?  I'm sure my terminology isn't correct, let
me explain....


I'm already able to connect to my Luminary 6965 eval board using OpenOCD
and debug that way.  However, I'm wondering if I can debug code without
the eval board, by using simulation only.  For right now, I'm only
interested in core debugging; peripherals would be nice but not required
at this time.  Also, if this can be done, is a good way provided to time
execution?

The simulation provided in Microchip MPLAB was very good, and I've
become spoiled.

qemu offers an emulator Cortex-M3 even explicitly for the LM3S6965
according to http://bellard.org/qemu/qemu-doc.html#SEC63 . qemu can
listen as a gdb-server so the chain Eclipse <-> gdb (to "remote") <->
gdb-server(qemu) <-> simulator(qemu) should be possible ("should" since
I have not tested this myself).

Martin Thomas wrote:
> qemu offers an emulator Cortex-M3 even explicitly for the LM3S6965
> according to http://bellard.org/qemu/qemu-doc.html#SEC63 . qemu can
> listen as a gdb-server so the chain Eclipse <-> gdb (to "remote") <->
> gdb-server(qemu) <-> simulator(qemu) should be possible ("should" since
> I have not tested this myself).

This looks interesting, but is thoroughly confusing me.  The "readme"
says to run qemu-win.bat, which launches Linux within Windows.  But I
can't figure out what the purpose of that is.  I'm not finding any files
in this filesystem that look different than the normal Linux filesystem.

http://bellard.org/qemu/qemu-doc.html#SEC63 says in order use gdb, this
following command should be issued:

qemu -s -kernel arch/i386/boot/bzImage -hda root-2.4.20.img

Except, it doesn't work because it can't open the disk image, and that
file doesn't exist.

On the same webpage, it states "Use the executable `qemu-system-arm' to
simulate a ARM machine."  The problem is, it seems like the executable
insists on a disk image of some sort, when I'm only trying to simulate a
microcontroller.  Uggghhhh.

Wouldn't arm-none-eabi-gdb work as a debugger with Eclipse?  This is my
guess, but I'm a little new at this aspect.

>
> Except, it doesn't work because it can't open the disk image, and that
> file doesn't exist.
>
> On the same webpage, it states "Use the executable `qemu-system-arm' to
> simulate a ARM machine."  The problem is, it seems like the executable
> insists on a disk image of some sort, when I'm only trying to simulate a
> microcontroller.  Uggghhhh.
>
> Wouldn't arm-none-eabi-gdb work as a debugger with Eclipse?  This is my
> guess, but I'm a little new at this aspect.

to run a compiled app under qemu use the following:
qemu-system-arm.exe -S -s -p 2000 -L . -kernel hello.elf -M lm3s811evb

This will stop the app at reset and wait for a gdb connection on port
2000

normally you could use the gdb simulator - but at the moment it does not
simulate atmv7 instructions very well.

Cheers
Spen

Spencer Oliver wrote:
>>
>
>
> to run a compiled app under qemu use the following:
> qemu-system-arm.exe -S -s -p 2000 -L . -kernel hello.elf -M lm3s811evb
>
> This will stop the app at reset and wait for a gdb connection on port
> 2000
>
> normally you could use the gdb simulator - but at the moment it does not
> simulate atmv7 instructions very well.
>
> Cheers
> Spen

Thank you for your reply.  I was able to execute the command you gave.
I'm still having a problem maybe you or someone else can provide some
input on.

I start arm-none-eabi-gdb with "-d" and some source directories, so far
so good.  Then I issue these commands within gdb:


(gdb) file hello.elf
Reading symbols from C:\(long path)\hello.ef...done.
(gdb) display/i $pc
(gdb) target extended-remote localhost:2000
Remote debugging using localhost:2000
0x00000000 in g_pfnVectors ()
1: x/i $pc
0x0 <g_pfnVectors>:     andcs   r0, r0, r8, lsl #14
(gdb) step
Single stepping until exit from function g_pfnVectors,
which has no line number information.
IntDefaultHandler () at startup.c:208
208     {
1: x/i $pc
0x9988 <IntDefaultHandler>:     b.n     0x9988 <IntDefaultHandler>
(gdb) step
IntDefaultHandler () at startup.c:208
208     {
1: x/i $pc
0x9988 <IntDefaultHandler>:     b.n     0x9988 <IntDefaultHandler>
Quit (expect signal SIGINT when the program is resumed)
(gdb) bt
#0  IntDefaultHandler () at startup.c:208
#1  0xfffffff8 in ?? ()
(gdb) info frame
Stack level 0, frame at 0xffffffe0:
 pc = 0x9988 in IntDefaultHandler (startup.c:208); saved pc 0xfffffff8
 called by frame at 0x0
 source language c.
 Arglist at 0xffffffe0, args:
 Locals at 0xffffffe0, Previous frame's sp is 0xffffffe0
(gdb)


I'm at a loss because this file, when programmed on an eval board, runs
fine.  It appears that at the reset vector, 0x0, it tried executing
"andcs" which isn't even a valid cortex-m3 instruction.  It throws a
Usage Exception, and branches to that handler, IntDefaultHandler, which
is just a while(1); loop.

What I don't understand:
1. Why does it work on the eval board
2. Why is there garbage at address 0x0 when I call main() in the reset
vector
3. What is the deal with the references to addresses near 0xffffffff

On a side note, any idea how to get a nice comprehensive assembly
listing from gcc?  -S causes all sorts of errors.

>
> Thank you for your reply.  I was able to execute the command you gave.
> I'm still having a problem maybe you or someone else can provide some
> input on.
>
> I start arm-none-eabi-gdb with "-d" and some source directories, so far
> so good.  Then I issue these commands within gdb:
>
>
> (gdb) file hello.elf
> Reading symbols from C:\(long path)\hello.ef...done.
> (gdb) display/i $pc
> (gdb) target extended-remote localhost:2000
> Remote debugging using localhost:2000
> 0x00000000 in g_pfnVectors ()
> 1: x/i $pc
> 0x0 <g_pfnVectors>:     andcs   r0, r0, r8, lsl #14
> (gdb) step
> Single stepping until exit from function g_pfnVectors,
> which has no line number information.
> IntDefaultHandler () at startup.c:208
> 208     {
> 1: x/i $pc
> 0x9988 <IntDefaultHandler>:     b.n     0x9988 <IntDefaultHandler>
> (gdb) step
> IntDefaultHandler () at startup.c:208
> 208     {
> 1: x/i $pc
> 0x9988 <IntDefaultHandler>:     b.n     0x9988 <IntDefaultHandler>
> Quit (expect signal SIGINT when the program is resumed)
> (gdb) bt
> #0  IntDefaultHandler () at startup.c:208
> #1  0xfffffff8 in ?? ()
> (gdb) info frame
> Stack level 0, frame at 0xffffffe0:
>  pc = 0x9988 in IntDefaultHandler (startup.c:208); saved pc 0xfffffff8
>  called by frame at 0x0
>  source language c.
>  Arglist at 0xffffffe0, args:
>  Locals at 0xffffffe0, Previous frame's sp is 0xffffffe0
> (gdb)
>
>
> I'm at a loss because this file, when programmed on an eval board, runs
> fine.  It appears that at the reset vector, 0x0, it tried executing
> "andcs" which isn't even a valid cortex-m3 instruction.  It throws a
> Usage Exception, and branches to that handler, IntDefaultHandler, which
> is just a while(1); loop.
>
> What I don't understand:
> 1. Why does it work on the eval board
> 2. Why is there garbage at address 0x0 when I call main() in the reset
> vector
> 3. What is the deal with the references to addresses near 0xffffffff
>
> On a side note, any idea how to get a nice comprehensive assembly
> listing from gcc?  -S causes all sorts of errors.

just for testing, change to target remote rather than extended-remote.
one point i would make is check you use the following in your linker
script:
ENTRY(ResetISR) /* change to suit your reset vector */

gdb sometimes get confused with the armv7(cortex_m3) as the reset vector
is not at 0 like most arm cores.

A lot depends on your version of gdb, mainline does not correctly
support v7 whereas codesourcery version does if you have sent the
correct target.xml file from your gdbserver.

remember qemu does not simulated everything, it is work in progress.

Cheers
Spen

Spencer Oliver wrote:
>>

>> listing from gcc?  -S causes all sorts of errors.
>
> just for testing, change to target remote rather than extended-remote.
> one point i would make is check you use the following in your linker
> script:
> ENTRY(ResetISR) /* change to suit your reset vector */
>
> gdb sometimes get confused with the armv7(cortex_m3) as the reset vector
> is not at 0 like most arm cores.
>
> A lot depends on your version of gdb, mainline does not correctly
> support v7 whereas codesourcery version does if you have sent the
> correct target.xml file from your gdbserver.
>
> remember qemu does not simulated everything, it is work in progress.
>
> Cheers
> Spen

Thanks again.  I'll look into this.