Propeller-GCC 1_9_0 GDB

jazzed

Started hooking up gdb to simpleide.

Having a bit of trouble. Is cogstart is supported yet?


Program running in LMM mode. Libraries built in LMM mode. Code attached.

Starting gdb ... GNU gdb (propellergcc-alpha_v1_9_0_) 7.9.50.20150415-cvs
Copyright (C) 2015 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "--host=i586-mingw32msvc --target=propeller-elf".
Type "show configuration" for configuration details.
For bug reporting instructions, please see:
<http://code.google.com/p/propgcc/issues>.
Find the GDB manual and other documentation resources online at:
<http://www.gnu.org/software/gdb/documentation/>.
For help, type "help".
Type "apropos word" to search for commands related to "word"...
Reading symbols from lmm/PacketTest.elf...done.
(gdb) set listsize 1
(gdb) target remote | "C:/Program Files (x86)/SimpleIDE/propeller-gcc/bin/gdbstub.exe" -v -l gdblog.txt
Remote debugging using | "C:/Program Files (x86)/SimpleIDE/propeller-gcc/bin/gdbstub.exe" -v -l gdblog.txt
0x00000048 in start ()
(gdb) set remote hardware-breakpoint-limit 1
(gdb) break main
warning: Can not parse XML memory map; XML support was disabled at compile time
Breakpoint 1 at 0x488: file PacketTest.c, line 19.
(gdb) continue
Continuing.


Breakpoint 1, main () at PacketTest.c:19
19    {
(gdb) step


Breakpoint 1, main () at PacketTest.c:19
19    {
(gdb) step
main () at PacketTest.c:21
21        pktport = fdserial_open(PROD_RX, PROD_TX, PROD_MODE, PROD_BAUD);
(gdb) step
26        printi("Send packets\n");
(gdb) step
21        pktport = fdserial_open(PROD_RX, PROD_TX, PROD_MODE, PROD_BAUD);
(gdb) step
23        printi("Packet Test\n");
(gdb) step
21        pktport = fdserial_open(PROD_RX, PROD_TX, PROD_MODE, PROD_BAUD);
(gdb) step
23        printi("Packet Test\n");
(gdb) step
Packet Test


24        packet_start(pktport);
(gdb) step
packet_start (rec=0x2440) at packet.c:26
26        grec = rec;
(gdb) step
27        gcog = cogstart(packet_cog, 0, packet_stack, sizeof(packet_stack));
(gdb) step
26        grec = rec;
(gdb) step
27        gcog = cogstart(packet_cog, 0, packet_stack, sizeof(packet_stack));
(gdb) step
Remote failure reply: E04
warning: Error removing breakpoint 0


Program received signal SIGTRAP, Trace/breakpoint trap.
Cannot remove breakpoints because program is no longer writable.
Further execution is probably impossible.
0x00000000 in start ()
(gdb)

Project Directory: C:/Users/Steve/Documents/SimpleIDE/PacketProducer/


SimpleIDE Version 1.0.2
C:/Users/Steve/Documents/SimpleIDE/Learn/Simple Libraries/
C:/Users/Steve/Documents/SimpleIDE/ Updated on: 2015-01-13


propeller-elf-gcc.exe -v GCC 4.6.1 (propellergcc-alpha_v1_9_0_)
propeller-elf-gcc.exe -I . -L . -I C:/Users/Steve/Documents/SimpleIDE/Learn/Simple Libraries/TextDevices/libsimpletext -L C:/Users/Steve/Documents/SimpleIDE/Learn/Simple Libraries/TextDevices/libsimpletext/lmm/ -I C:/Users/Steve/Documents/SimpleIDE/Learn/Simple Libraries/TextDevices/libfdserial -L C:/Users/Steve/Documents/SimpleIDE/Learn/Simple Libraries/TextDevices/libfdserial/lmm/ -g -Os -mlmm -Wall -m32bit-doubles -fno-exceptions -std=c99 -g -c packet.c -o lmm/packet.o
propeller-elf-gcc.exe -I . -L . -I C:/Users/Steve/Documents/SimpleIDE/Learn/Simple Libraries/TextDevices/libsimpletext -L C:/Users/Steve/Documents/SimpleIDE/Learn/Simple Libraries/TextDevices/libsimpletext/lmm/ -I C:/Users/Steve/Documents/SimpleIDE/Learn/Simple Libraries/TextDevices/libfdserial -L C:/Users/Steve/Documents/SimpleIDE/Learn/Simple Libraries/TextDevices/libfdserial/lmm/ -g -o lmm/PacketTest.elf -Os -mlmm -Wall -m32bit-doubles -fno-exceptions -std=c99 -g lmm/packet.o PacketTest.c -lsimpletext -lfdserial -lsimpletext
propeller-load -s lmm/PacketTest.elf
propeller-elf-objdump -h lmm/PacketTest.elf
Done. Build Succeeded!


propeller-load.exe -Dreset=dtr -I C:/Program Files (x86)/SimpleIDE/propeller-gcc/propeller-load/ -b ACTIVITYBOARD lmm/PacketTest.elf -g -r -p COM4
Propeller Version 1 on COM4


patching for debug at offset 0x1fb0
Loading lmm/PacketTest.elf to hub memory
9464 bytes sent


Verifying RAM ... 
OK

ersmith

fdserial is going to take over the serial port, and then gdb will lose its connection (actually I guess it's worse than that, fdserial and the kernel debug stub will fight over the serial pins and neither one will be able to do anything).

I made some attempts at having COGs be able to share the serial pins, but they all foundered on the shoals of the quickstart hardware (which I think you're well familiar with ).

ersmith

Hmmm... looking over the log I'm amazed that it got as far as it did. I would have expected it to die after the fdserial_open, and definitely would not have expected it to make it past a print using fdserial. Is this fdserial running in another COG?

jazzed

ersmith wrote: »

Hmmm... looking over the log I'm amazed that it got as far as it did. I would have expected it to die after the fdserial_open, and definitely would not have expected it to make it past a print using fdserial. Is this fdserial running in another COG?

Hi Eric,

The fdserial is running in another COG. It is also using pin 0/1 for communications instead of the default 30/31 pins. So, there shouldn't be any problems with pin fighting.

I'm also amazed it got as far as it did ... I only spent an hour on it this morning.

Thanks.

jazzed

Tried stepping through a different program this morning (in LMM mode).

The -Os optimization reorders code quite a bit. I changed optimization to -O1, and the basic stepping order is normal.

Of course -O1 optimization is not very good for generating small code. Is there an optimization flag that I can add in the -Os case to maintain order and keep the binary code small?

I'll look at "hover-over variable" inspection next.

I haven't tried CMM since the help page suggests that it doen't work yet.

ersmith

For gcc4 -O1 is probably the most usable option for debugging (you might be able to play around with various individual optimizations using the many, many -f options of gcc, and some of them might improve things, but it's a huge matrix to test ).

gcc5 has a -Og option which is supposed to enable all the optimizations that don't interfere with debugging. I haven't actually tried it out yet.

I think gdb for CMM will work in practice, it just hasn't been tested much. It's not like gdb on LMM has been tested very much either, though!

jazzed

Thanks Eric.

Should I be testing gcc5?
I suppose that would be the closest to integrating to the main GNU repo.

---

Tried CMM mode with libsimpletext, and found that "next" stumbles on the line below.
Using "step" through the function seemed to work. No trouble with LMM "next".

libsimpletext.c line 48: simpleterm_reopen(31,30,0,115200);

Thanks.

David Betz

jazzed wrote: »

Thanks Eric.

Should I be testing gcc5?
I suppose that would be the closest to integrating to the main GNU repo.

---

Tried CMM mode with libsimpletext, and found that "next" stumbles on the line below.
Using "step" through the function seemed to work. No trouble with LMM "next".

libsimpletext.c line 48: simpleterm_reopen(31,30,0,115200);

Thanks.

If you decide to go with GCC5, someone (maybe me I suppose) will have to fix the GDB build on the Macintosh. I made a first stab at it but wasn't successful. The Xcode compiler seems a lot more picky than it used to be and I couldn't get it to build GDB. An older version of Xcode might have more luck though. I'm running the latest release. Currently, GDB is disabled in the Mac build that incorporates GCC5.

ersmith

jazzed wrote: »

Should I be testing gcc5?

It's not quite ready for prime time yet. We could use any testing you can give, but it may not be the best starting point for adding gdb support to simpleide.

I suppose that would be the closest to integrating to the main GNU repo.

It's a fork of the main GNU repo, and we can periodically merge from that.

Sorry you had some trouble with CMM -- I guess there was a good reason we added that note to the docs . I looked briefly at the code, and it looks like we need to add some support for parsing function prologues in CMM mode. I'm not sure how hard that will be -- probably not too bad, but I can't get to it for a few days (I'd be happy to help any volunteers that want to look at the gdb code, though!)

Eric

jazzed

Adding variable inspection to the IDE. Test program below.

Observations:
1. gval is never "in context" in CMM or LMM
2. val is always "in context" in CMM or LMM
3. n is only "in context" before the for loop is started

Not sure if anyone will ever have time for the issues. At this point it may not be worth pursuing further unless Parallax wants it.

/**
 * This is the main gdbtest1 program file.
 */
#include "simpletext.h"


int gval = 0x55;


int main(void)
{
  int n;
  int val;
  for (n = 0; n < 10; n++) {
    val = gval+n;
    printi("value[%d] %d\n", n, val);
  }  
  return val;
}

lmm gdb trace

Breakpoint 1, main () at gdbtest1.c:9
9    {
(gdb) next
main () at gdbtest1.c:12
12      for (n = 0; n < 10; n++) {
(gdb) p n
$1 = 0
(gdb) p n
$2 = 0
(gdb) p val
$3 = 0
(gdb) p gval
No global symbol "gval".
(gdb) next
13        val = gval+n;
(gdb) next
14        printi("value[%d] %d\n", n, val);
(gdb) next
13        val = gval+n;
(gdb) p n
$4 = <optimized out>
(gdb) next
14        printi("value[%d] %d\n", n, val);
(gdb) next
value[0] 85


12      for (n = 0; n < 10; n++) {
(gdb) next
13        val = gval+n;
(gdb) next
14        printi("value[%d] %d\n", n, val);
(gdb) p n
$5 = <optimized out>
(gdb) next
value[1] 86


12      for (n = 0; n < 10; n++) {
(gdb) p val
$6 = 86
(gdb) 

ersmith

Thanks for trying gdb out, Steve. I haven't had much time to work on propeller stuff lately, but when I get a break from paying work I'll try to fix those gdb bugs.

Eric