Shop OBEX P1 Docs P2 Docs Learn Events
Debugger and other Plans? — Parallax Forums

Debugger and other Plans?

Christof Eb.Christof Eb. Posts: 1,234
edited 2013-03-02 08:49 in Propeller 1
Hi,
some time ago I had had the impression, that it was planned to integrate a source level debugger into the GCC environment.
Will there be such feature?

Another question:
Will there be some kind of library with explanations for basic functions like the existing library for SPIN?
(At this moment for example I am wondering, how to interface servos with GCC)

Best regards,
Christof

Comments

  • David BetzDavid Betz Posts: 14,516
    edited 2013-03-02 05:00
    Christof Eb. wrote: »
    Hi,
    some time ago I had had the impression, that it was planned to integrate a source level debugger into the GCC environment.
    Will there be such feature?
    We're working on the debugger in the context of a new release that will also support the Propeller 2. If you'd like to try it, there is a test release for Windows in the downloads section of Google Code:

    http://code.google.com/p/propgcc/downloads/detail?name=prop2gcc-2013-02-26.zip&can=2&q=

    This version includes the command-line version of gdb. If you need a GUI debugger you'll have to try one of the GUI frontends for gdb.
    Another question:
    Will there be some kind of library with explanations for basic functions like the existing library for SPIN?
    (At this moment for example I am wondering, how to interface servos with GCC)
    I believe that Parallax is hard at work on something like this as we speak. I'm sure you can expect the exceptional quality of Parallax documention for their C/C++ product just like we've all appreciated for Spin.
  • RaymanRayman Posts: 14,826
    edited 2013-03-02 06:04
    Can you give a simple description of how the debugger works? Does it run in a seperate cog?
    Is it more like a monitor? Or, can you implement breakpoints?
  • David BetzDavid Betz Posts: 14,516
    edited 2013-03-02 06:24
    Rayman wrote: »
    Can you give a simple description of how the debugger works? Does it run in a seperate cog?
    Is it more like a monitor? Or, can you implement breakpoints?
    It's just gdb. It doesn't require a separate COG. The debugger runs on a PC and communicates with the Propeller over a serial link. This is a fairly standard way for gdb to operate. Yes, it does support breakpoints. It's currently implemented for LMM and XMM modes on the P1 and LMM on the P2. It will eventually be available for CMM and XMM on the P2.
  • David BetzDavid Betz Posts: 14,516
    edited 2013-03-02 06:57
    Here are Eric's quick instructions on how to debug a program on the P1. Just do the same thing for the P2 except add the -mp2 option to any build and link commands.
    (1) Compile with the -g flag: 
    propeller-elf-gcc -o p2.elf test.c

    (2) Load and run with the -g flag: 
    propeller-load -bde2-115 p2.elf -g -r

    (3) Run propeller-elf-gdb: 
    propeller-elf-gdb p2.elf

    propeller-elf-gdb automatically loads a "gdbinit" file which contains the command target remote |gdbstub so you don't have to type this. Instead you can immediately start issuing commands to gdb.

    For example, to set a breakpoint on main just do:
    break main

    To get the program to run, type "c" (or "continue") after you've set all breakpoints you want.
  • ersmithersmith Posts: 6,092
    edited 2013-03-02 07:01
    Rayman wrote: »
    Can you give a simple description of how the debugger works? Does it run in a seperate cog?
    Is it more like a monitor? Or, can you implement breakpoints?

    David gave the basics, but I'll expand on it a little bit:

    When compiled for debugging (-g option) the application uses a slightly different LMM or XMM kernel, which has a simpler loop and also checks for a single step flag, breakpoints (for XMM mode; in LMM mode the breakpoint can be inserted directly into the code in RAM), and serial interrupt from the host. A simple serial protocol is used to communicate between the COG and the host, where a program called "gdbstub" interfaces with the gdb debugger.

    The way you run the debugger is:

    (1) Use propeller-load to run the application, but give it the -g flag to say you want to debug (and do not add -t to stay in terminal mode):
    propeller-load -bc3 foo.elf -r -g
    This starts the app and sets the "single step" bit in the LMM kernel, so the COG immediately drops into the debug stub.

    (2) Launch propeller-elf-gdb
    propeller-elf-gdb foo.elf

    (3) Set breakpoints and interact with the program as you normally would with gdb, which is a very powerful command line source level debugger (there's lots of documentation out there on the web for it). In XMM mode only 2 breakpoints can be set in ROM (the XMM kernel checks the address of the next instruction to execute against a list of breakpoints) so things are a bit restricted. Any number of breakpoints may be placed on XMM code in HUB memory, or in LMM code; in thise case the breakpoint is performed by inserting a "call #__EnterDebugger" instruction at the point where the program should break (after backing up the original instruction, of course!)

    Currently the debugger only supports single threaded programs (one C COG). The protocol is set up for multiple COG support, but we haven't finished integrating that with gdb yet.

    Eric
  • Christof Eb.Christof Eb. Posts: 1,234
    edited 2013-03-02 08:49
    Thank you for your quick and positive answers!
    As my PPMM (Personally Preferred Memory Model) is CMM, I hope for debugger support of that....

    All my old dreams for a Propeller language are coming true:
    Fast,
    well documented,
    with floating-point support,
    usefully working with the restricted on chip memory,
    having a debugger.

    This is great!
    Christof
Sign In or Register to comment.