GDB over serial ready or coming?

Rayman · 2013-04-06 07:44

No luck... Still had to copy over the two .lib files to make gdb talk and then it acts the same way...

Tried "r" and it gives "Don't know how to run. Try "help target""

Tried "target remote |gdbstub" and it gives "error waiting for inital resonse from dummy debug kernet"...

Tried "target remote \\.\\\\COM20" (because I'm on COM20) and this one seems to make it try to talk, can see leds flashing, but just gives:
"Ignoring packet error, continuing..." then "warning: unrecognized item "timeout" in "qSupported" response"

jazzed · 2013-04-06 08:02

Rayman wrote: »

No luck...

This is using a CMD window? Can you post all the steps done from the compile step?

David Betz · 2013-04-06 08:04

Rayman wrote: »

No luck... Still had to copy over the two .lib files to make gdb talk and then it acts the same way...

Tried "r" and it gives "Don't know how to run. Try "help target""

Tried "target remote |gdbstub" and it gives "error waiting for inital resonse from dummy debug kernet"...

Tried "target remote \\.\\\\COM20" (because I'm on COM20) and this one seems to make it try to talk, can see leds flashing, but just gives:
"Ignoring packet error, continuing..." then "warning: unrecognized item "timeout" in "qSupported" response"

I don't think you want to specify the com port with the "target remote" command. gdbstub knows how to find the com port. I think you just need "target remote | gdbstub".

Rayman · 2013-04-06 08:11

target remote |gdbstub does the same thing "error waiting..."

Here's my build script, the source file, and the text from cmd window:
GDB_Win7Test.zip

jazzed · 2013-04-06 08:26

Do you google+ ?

Rayman · 2013-04-06 08:31

sorry, no social media here...
Tried some more things, but GDB doesn't even look like it's trying to talk to the Prop except when given "target remote \\.\\\\COM20"

Any chance it has something to do with those two library files I copied over from MinGW?

BTW: Have you seen this working on a real Windows7 machine?

jazzed · 2013-04-06 09:26

Rayman wrote: »

sorry, no social media here...
Tried some more things, but GDB doesn't even look like it's trying to talk to the Prop except when given "target remote \\.\\\\COM20"

It should be "target remote | gdbstub -p port" ...

To me social media is more trouble than it's worth except that google+ has a great desktop/app viewing and chat feature for helping solve issues.

jazzed · 2013-04-06 09:32

David, your package is still missing the .dll files. Those files must be added from your mingw/msys distribution.

Rayman · 2013-04-06 09:34

same thing...

D:\Propeller2\VisualStudio\Demos_P1_WinGDB\Hello_GDB>build
D:\Propeller2\VisualStudio\Demos_P1_WinGDB\Hello_GDB>propeller-elf-gcc -g -o hel
lo.elf hello.c
D:\Propeller2\VisualStudio\Demos_P1_WinGDB\Hello_GDB>propeller-load -bc3 hello.e
lf -r
Propeller Version 1 on COM20
Loading hello.elf to hub memory
6520 bytes sent
Verifying RAM ... OK
D:\Propeller2\VisualStudio\Demos_P1_WinGDB\Hello_GDB>build
D:\Propeller2\VisualStudio\Demos_P1_WinGDB\Hello_GDB>propeller-elf-gcc -g -o hel
lo.elf hello.c
D:\Propeller2\VisualStudio\Demos_P1_WinGDB\Hello_GDB>propeller-load -bc3 hello.e
lf -r
Propeller Version 1 on COM20
Loading hello.elf to hub memory
6520 bytes sent
Verifying RAM ... OK
D:\Propeller2\VisualStudio\Demos_P1_WinGDB\Hello_GDB>propeller-elf-gdb hello.elf
GNU gdb (GDB) 7.3.1
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <[URL]http://gnu.org/licenses/gpl.html[/URL]>
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=i686-pc-mingw32 --target=propeller-elf".
For bug reporting instructions, please see:
<[URL]http://www.gnu.org/software/gdb/bugs/[/URL]>...
Reading symbols from D:\Propeller2\VisualStudio\Demos_P1_WinGDB\Hello_GDB/hello.
elf...done.
(gdb) target remote | gdbstub
Remote debugging using | gdbstub
error waiting for initial response from dummy debug kernel
Remote communication error.  Target disconnected.: No error.
(gdb)

jazzed · 2013-04-06 09:38

Rayman, it should be "target remote | gdbstub -p port"

I edited my post below, but not sure if you saw that.

Rayman · 2013-04-06 09:42

Well, it tries at least with that (can see leds flash), but doesn't work:

(gdb) target remote | gdbstub -p COM20
Remote debugging using | gdbstub -p COM20
error waiting for initial response from dummy debug kernel
Remote communication error.  Target disconnected.: No error.
(gdb)

Never mind, this works "target remote | gdbstub -p COM20"

When I was trying things a minute ago, I left off the "-g" on propeller-load...

Rayman · 2013-04-06 09:49

It works! Thanks, jazzed. Ignore above post...

Here's it working with "target remote | gdbstub -p COM20"

D:\Propeller2\VisualStudio\Demos_P1_WinGDB\Hello_GDB>propeller-elf-gdb hello.elf
GNU gdb (GDB) 7.3.1
Copyright (C) 2011 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <[URL]http://gnu.org/licenses/gpl.html[/URL]>
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=i686-pc-mingw32 --target=propeller-elf".
For bug reporting instructions, please see:
<[URL]http://www.gnu.org/software/gdb/bugs/[/URL]>...
Reading symbols from D:\Propeller2\VisualStudio\Demos_P1_WinGDB\Hello_GDB/hello.
elf...done.
(gdb) target remote | gdbstub -p COM20
Remote debugging using | gdbstub -p COM20
0x000005b0 in start ()
(gdb) r
The "remote" target does not support "run".  Try "help target" or "continue".
(gdb) break main
warning: Can not parse XML memory map; XML support was disabled at compile time
Breakpoint 1 at 0x674: file hello.c, line 11.
(gdb) c
Continuing.
Breakpoint 1, main () at hello.c:11
11          printf("hello, world!\n");
(gdb) c
Continuing.
Breakpoint 1, main () at hello.c:11
11          printf("hello, world!\n");
(gdb) c
Continuing.
hello, world!
goodbye, world!

jazzed · 2013-04-06 09:50

I'm having the same .dll troubles ... and I don't see libintl* in the mingy/msys distribution.

There is a libintl.a in mingw though. Maybe that should be statically linked? Mingw's license allows static linking.

jazzed · 2013-04-06 09:58

Good. Thanks for your perseverance Rayman.

@David I found libintl-8.dll and others in the mingw/bin directory. Not sure why such things are not in lib.

but... they are in your package ....

Hmm. Looks like a version problem in my case as I use a different mingw/msys that has it's own libintl-8.dll .... Removed the propeller-gcc/bin/lib* files and everything is working normally - not necessary to do for most users.

David Betz · 2013-04-06 10:01

Rayman wrote: »
Well, it tries at least with that (can see leds flash), but doesn't work:
(gdb) target remote | gdbstub -p COM20
Remote debugging using | gdbstub -p COM20
error waiting for initial response from dummy debug kernel
Remote communication error.  Target disconnected.: No error.
(gdb)
Never mind, this works "target remote | gdbstub -p COM20"

When I was trying things a minute ago, I left off the "-g" on propeller-load...

Okay, I think I understand. If you let gdbstub find the port itself it will trash the program that you just loaded with propeller-load. I guess we need a better way to start the stub.

David Betz · 2013-04-06 10:03

jazzed wrote: »

Good. Thanks for your perseverance Rayman.

@David I found libintl-8.dll and others in the mingw/bin directory. Not sure why such things are not in lib.

but... they are in your package. Now i'm lost.

What other DLLs are needed? We already have libintl-8.dll but it must be an old version. What other libraries are needed?

jazzed · 2013-04-06 10:11

Looks like I was wrong about run ... sorry.

sh-3.1$ propeller-elf-gdb a.out
GNU gdb (GDB) 7.3.1
Copyright (C) 2011 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=i686-pc-mingw32 --target=propeller-elf".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
Reading symbols from c:\Users\Steve\Documents\SimpleIDE\My Projects/a.out...done.
(gdb) target remote | gdbstub -p COM16
Remote debugging using | gdbstub -p COM16
0x000005b0 in start ()
(gdb) b main
warning: Can not parse XML memory map; XML support was disabled at compile time
Breakpoint 1 at 0x674: file Blank Simple Project.c, line 16.
(gdb) r
The "remote" target does not support "run".  Try "help target" or "continue".
(gdb) c
Continuing.


Breakpoint 1, main () at Blank Simple Project.c:16
16        }
(gdb)

jazzed · 2013-04-06 10:36

David Betz wrote: »

What other DLLs are needed? We already have libintl-8.dll but it must be an old version. What other libraries are needed?

My problem as it turns out is that I already have a different version of Mingw installed. I had to remove the .dll's.

Rayman · 2013-04-06 10:37

Here are the two .dll files that I had to manually copy from the MinGW install directory to make it work:
libintl-8.zip

David Betz · 2013-04-06 10:42

Rayman wrote: »

Here are the two .dll files that I had to manually copy from the MinGW install directory to make it work:
libintl-8.zip

Thanks for letting me know which DLLs are needed. I'll add them to Steve's release folder so they'll be included in the next zip file.

Rayman · 2013-04-06 11:45

David Betz wrote: »

Okay, I think I understand. If you let gdbstub find the port itself it will trash the program that you just loaded with propeller-load. I guess we need a better way to start the stub.

I don't think that's it... I don't think it even looked at the ports...
Or, maybe it just tried COM1...

So, just for fun, I copied gbdinit to the propgcc\bin folder and added the port spec like this:

target remote |gdbstub -p COM20
set remote hardware-breakpoint-limit 1

Then, I can make it connect on startup with this:

propeller-elf-gdb hello.elf -x c:\propgcc\bin\gdbinit

Not sure why I had to add the full path to gdbinit, btw...

Rayman · 2013-04-06 18:04

Maybe you could have the loader write out a new gdbinit file each time it's run?

(one that says which com port to use...)

David Betz · 2013-04-06 18:28

Rayman wrote: »
I don't think that's it... I don't think it even looked at the ports...
Or, maybe it just tried COM1...

So, just for fun, I copied gbdinit to the propgcc\bin folder and added the port spec like this:
target remote |gdbstub -p COM20
set remote hardware-breakpoint-limit 1
Then, I can make it connect on startup with this:
propeller-elf-gdb hello.elf -x c:\propgcc\bin\gdbinit
Not sure why I had to add the full path to gdbinit, btw...

If you use the -p option that disables the auto-port detection. Are you sure that isn't what is causing the problem? In order to detect a Propeller on a port, gdbstub needs to reset the Propeller and that will obviously stop whatever program you loaded.

Rayman · 2013-04-06 18:55

I'm positive that the propeller isn't being reset...

I'm testing today with a QMP on top of Quickstart. The Quickstart has eeprom loaded with graphics demo for QMP.
If the Quickstart were to reset, the LCD screen would come on and show the graphics demo...

David Betz · 2013-04-06 19:24

Rayman wrote: »

I'm positive that the propeller isn't being reset...

I'm testing today with a QMP on top of Quickstart. The Quickstart has eeprom loaded with graphics demo for QMP.
If the Quickstart were to reset, the LCD screen would come on and show the graphics demo...

Is that true even if the PC sends the loader initialization sequence to get the chip id?

Rayman · 2013-04-06 20:07

Not sure what you mean... The loader definitely resets and loads HUB RAM...

But, none of my tests with propeller-elf-gdb resulted in a reset....

Except I think maybe the Prop resets when you "quit" from GDB, have to check on that to be sure...

David Betz · 2013-04-06 20:24

Rayman wrote: »

Not sure what you mean... The loader definitely resets and loads HUB RAM...

But, none of my tests with propeller-elf-gdb resulted in a reset....

Except I think maybe the Prop resets when you "quit" from GDB, have to check on that to be sure...

What I mean is that if you don't use the -p option with gdbstub it scans all of the ports on your computer looking for a Propeller chip. To determine if there is a Propeller chip attached, it resets the Propeller by toggling DTR and sends an ID sequence to determine what type of chip is on that port. I would think that process would halt any program you had run prior to running gdbstub. At least this is the way it used to work. Maybe the port scanning has been disabled in recent versions. I guess I need to check this out or maybe Eric will know.

ersmith · 2013-04-07 05:28

David Betz wrote: »

What I mean is that if you don't use the -p option with gdbstub it scans all of the ports on your computer looking for a Propeller chip. To determine if there is a Propeller chip attached, it resets the Propeller by toggling DTR and sends an ID sequence to determine what type of chip is on that port. I would think that process would halt any program you had run prior to running gdbstub. At least this is the way it used to work. Maybe the port scanning has been disabled in recent versions. I guess I need to check this out or maybe Eric will know.

I think had to disable the port scanning, for the reason you mentioned -- it resets the Prop, and gdbstub needs to interact with code that was loaded in the application. I guess we could write a new port scanning routine that tries sending the debug escape sequences on each port, looking for a response. Something to add to the "to-do" list!

Eric

GDB over serial ready or coming?

Comments