Because of the holidays, TI E2E™ design support forum responses will be delayed from Dec. 25 through Jan. 2. Thank you for your patience.

  • State Resolved
  • Locked Locked
  • Replies 6 replies
  • Subscribers 54 subscribers
  • Views 3967 views
  • Users 0 members are here
Support feedback
Options
Options
Similar topics

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

Debugging local console application in CCSv6

Jeanne Petrangelo
Prodigy 120 points

I have handwritten makefiles that build and run unit test executables using Cygwin g++; these unit test code for the MSP430 using the native g++ and they run on my PC from the Cygwin command line.  I can use gdb from the Cygwin command line to debug these executables without problem. I'd like to set up a debug configuration in CCS to use the graphical debugger interface.

So far I have done the following:

  Window > Preferences > General > Capabilities: Check box for "CDT GDB Debugging"

  Window > Preferences > C/C++ > Debug > GDB: Set "GDB Debugger" to C:\cygwin64\bin\gdb.exe

  Run > Debug Configurations:  Create a new "C/C++ Application" debug configuration. The application is the unit test executable which was built from the Cygwin command line.

When I try to launch this debug configuration, I get the following error (Note: I replaced the actual path and filename with "<my path>/utests" and there are no spaces in the actual path or filename):

Error in final launch sequence

Failed to execute MI command:

-file-exec-and-symbols C:/<my path>/utests.exe

Error message from debugger back end:

"C:/<my path>/utests.exe": not in executable format: File truncated

"C:/<my path>/utests.exe": not in executable format: File truncated

Why is this happening, and what do I need to do to get past this? I'm running CCSv6 under Windows 7. My CCS is up to date.

Thank you.

  • 0
    TI__Expert 5815 points

    Hello Jeanne,

    Thank you for posting on the E2E Community Forums!    Regarding your issue, just to verify, when creating your CCS project, did you select the "Makefile Project with existing code" template?   I would suggest reviewing this wiki article.    Please let us know what we can do to help.

    Regards,

    Sem Amesawu

  • 0
    Prodigy 120 points

    I should have mentioned, another thing I did was go to Window > Preferences > C/C++ > Debug > Source Lookup Path and added a path mapping of \cygdrive\c to C:\

    I found one problem, but I still cannot get the command line executable to run in the CCS debugger.

    In the project's properties, in C/C++ Build > Settings, I had checked "PE Windows Parser" but I should have checked "Cygwin PE Parser."  Now I don't get the same error as before.

    I also went to Window > Preferences > C/C++ > Debug > GDB and made sure to UNcheck "Stop on startup at: main"

    Now, when set a breakpoint in the unit test source file and try to run the debug configuration, the debug session terminates with "exit value: 0>gdb". I never see the breakpoint hit.  If I leave "Stop on startup at: main" checked, the same thing happens. I would expect to see similar behavior to when I'm using the CCS gdb to debug on my target hardware: the software starts at the beginning of main and I can then tell it to run.

  • 0 in reply to iConduct
    Prodigy 120 points

    Sem, no I had not. I'm trying to do this in the same CCS project that I use to cross compile. I'll try creating a new "makefile project with existing code" just for running and debugging the unit tests and post my results.

  • 0 in reply to Jeanne Petrangelo
    Prodigy 120 points

    Running the debugger from a different project, one that is a "new makefile project with existing code", does not change the behavior of the debugger from what I described.

    I don't intend to build the unit tests from within CCS as the makefile has multiple targets and it's simple enough to just invoke them from the Cygwin bash shell.

    The link you suggested is for a cross-compilation project; this is using Cygwin's native gcc.

  • 0 in reply to Jeanne Petrangelo
    Prodigy 120 points

    I have more information to help TI people familiar with how Eclipse interacts with gdb-mi to deal with this. I thought if I download regular Eclipse Kepler and try the same thing there, it would work and I could find out what was different, but it had the same problems, so it may be a problem with Eclipse Kepler.

    To get this problem down to basics, I created a simple Hello world program and built it at the command line with:

      gcc -g hello.c

    ... which created a.exe. I can use gdb from the command line to debug this program without problem; it starts at the top of main() and I can set a breakpoint at the line with the printf, run and it will run to the breakpoint. Fine.

    Whether I try to debug this from CCSv6 or Eclipse Kepler, the gdb-mi console ouput shows me this:

    150,885 2-gdb-set breakpoint pending on

    150,887 2^done

    150,887 (gdb)

    150,887 3-gdb-set detach-on-fork on

    150,888 3^done

    150,888 (gdb)

    150,888 4-enable-pretty-printing

    150,889 4^done

    150,889 (gdb)

    150,889 5-gdb-set python print-stack none

    150,890 5^done

    150,890 (gdb)

    150,890 6-gdb-set print object on

    150,891 6^done

    150,891 (gdb)

    150,891 7-gdb-set print sevenbit-strings on

    150,892 7^done

    150,892 (gdb)

    150,892 8-gdb-set host-charset UTF-8

    150,893 8^done

    150,893 (gdb)

    150,893 9-gdb-set target-charset WINDOWS-1252

    150,894 9^done

    150,894 (gdb)

    150,894 10-gdb-set target-wide-charset UTF-16

    150,895 10^done

    150,895 (gdb)

    150,895 11source C:\cygwin64\home\petranj\.gdbinit

    150,896 &"source C:\\cygwin64\\home\\petranj\\.gdbinit\n"

    150,896 11^done

    150,896 (gdb)

    150,897 12-gdb-set target-async off

    150,898 12^done

    150,898 (gdb)

    150,898 13-gdb-set auto-solib-add on

    150,899 13^done

    150,899 (gdb)

    150,900 14-file-exec-and-symbols --thread-group i1 C:/IntelligentD/scratch/a.exe

    150,923 14^done

    150,923 (gdb)

    150,923 15-data-evaluate-expression --thread-group i1 "sizeof (void*)"

    150,924 15^done,value="8"

    150,924 (gdb)

    150,924 16-interpreter-exec --thread-group i1 console "show endian"

    150,925 ~"The target endianness is set automatically (currently little endian)\n"

    150,925 16^done

    150,925 (gdb)

    150,925 17-break-insert --thread-group i1 -t -f main

    150,926 17^done,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x00000001004010dd",\

    func="main",file="hello.c",fullname="/cygdrive/c/IntelligentD/scratch/hello.c",line="5",thread-group\

    s=["i1"],times="0",original-location="main"}

    150,926 (gdb)

    150,928 18-exec-run --thread-group i1

    150,936 =thread-group-started,id="i1",pid="8908"

    150,936 19-list-thread-groups --available

    150,937 =thread-created,id="1",group-id="i1"

    150,937 ~"[New Thread 8908.0x25b0]\n"

    150,937 18^running

    150,937 *running,thread-id="all"

    150,937 (gdb)

    150,939 =thread-exited,id="1",group-id="i1"

    150,939 =thread-group-exited,id="i1"

    150,939 18^error,msg="During startup program exited with code 0xc0000135."

    150,939 (gdb)

    150,939 19^error,msg="Can not fetch data now."

    150,939 (gdb)

    151,386 20-gdb-exit

    151,387 21-data-evaluate-expression $_exitcode

    151,389 20^exit

     

    Now, when I run gdb from the command line as:

       gdb --interpreter=mi a.exe

    ... and enter in the same commands as you see above, something different happens when I get to step 18:

    (gdb)

    18-exec-run --thread-group i1

    =thread-group-started,id="i1",pid="9476"

    =thread-created,id="1",group-id="i1"

    ~"[New Thread 9476.0x24bc]\n"

    18^running

    *running,thread-id="all"

    (gdb)

    =library-loaded,id="/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll",target-name="/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll",host-name="/cygdrive/c/WINDOWS/SYSTEM32/ntdll.dll",symbols-loaded="0",thread-group="i1"

    =library-loaded,id="/cygdrive/c/WINDOWS/system32/kernel32.dll",target-name="/cygdrive/c/WINDOWS/system32/kernel32.dll",host-name="/cygdrive/c/WINDOWS/system32/kernel32.dll",symbols-loaded="0",thread-group="i1"

    =library-loaded,id="/cygdrive/c/WINDOWS/system32/KERNELBASE.dll",target-name="/cygdrive/c/WINDOWS/system32/KERNELBASE.dll",host-name="/cygdrive/c/WINDOWS/system32/KERNELBASE.dll",symbols-loaded="0",thread-group="i1"

    =library-loaded,id="/cygdrive/c/WINDOWS/System32/SYSFER.DLL",target-name="/cygdrive/c/WINDOWS/System32/SYSFER.DLL",host-name="/cygdrive/c/WINDOWS/System32/SYSFER.DLL",symbols-loaded="0",thread-group="i1"

    =library-loaded,id="/usr/bin/cygwin1.dll",target-name="/usr/bin/cygwin1.dll",host-name="/usr/bin/cygwin1.dll",symbols-loaded="0",thread-group="i1"

    =library-loaded,id="/cygdrive/c/WINDOWS/system32/psapi.dll",target-name="/cygdrive/c/WINDOWS/system32/psapi.dll",host-name="/cygdrive/c/WINDOWS/system32/psapi.dll",symbols-loaded="0",thread-group="i1"

    =thread-created,id="2",group-id="i1"

    ~"[New Thread 9476.0x24f4]\n"

    *running,thread-id="all"

    =breakpoint-modified,bkpt={number="1",type="breakpoint",disp="del",enabled="y",addr="0x00000001004010dd",func="main",file="hello.c",fullname="/cygdrive/c/IntelligentD/scratch/hello.c",line="5",thread-groups=["i1"],times="1",original-location="main"}

    ~"\nTemporary breakpoint "

    ~"1, main () at hello.c:5\n"

    ~"5\t printf(\"Hello world\\n\");\n"

    *stopped,reason="breakpoint-hit",disp="del",bkptno="1",frame={addr="0x00000001004010dd",func="main",args=[],file="hello.c",fullname="/cygdrive/c/IntelligentD/scratch/hello.c",line="5"},thread-id="1",stopped-threads="all"

    =breakpoint-deleted,id="1"

    (gdb)

     

    Can the folks at TI figure this out? You should be able to reproduce this by creating a simple Hello World executable from Cygwin as I did above, then in CCSv6 creating a debug configuration of type "C/C++ Application". In the debug configuration's Main tab, point the application to the executable, Project should be empty, disable auto build, and select the configuration using 'C\C++ Application.' In the Debugger tab, point the GDB debugger to C:\cygwin64\bin\gdb.exe, and the GDB command file to wherever you put an empty .gdbinit file. For the Source tab, add a Source Lookup Path that points directly to where hello.c is located. That should be it.

  • 0 in reply to Jeanne Petrangelo
    Prodigy 120 points

    Okay, I've solved it. I'll put all the relevant information in this one post for other people's benefit.

    I have a regular CCSv6 project for our MSP430-based product. It has the typical stuff: the project's home directory has a .project and a .cproject, we have source and header files in various subdirectories, and CCS creates Debug and Release subdirectories for those two build configurations. Additionally, I've created a Test subdirectory. Test contains handwritten makefiles which build subsets of the product's source code along with a unit test framework (in this case Google Test) to create unit test executables which are essentially Cygwin command-line programs that run on my PC, independently of the target hardware. I build and run these from the Cygwin shell, by hand. All of the build artifacts are put in the Test directory, just like CCS puts the Debug artifacts in the Debug directory and the Release artifacts in the Release directory.  This is a powerful way to prove the software's logic independently of the target hardware, and to help prevent regressions.

    As an aside, I experimented with using CCS to create managed makefiles using Cygwin's gcc for the unit tests as just another build confiration, but there were two main problems with that approach. The big one was that these makefiles couldn't handle incremental builds and I had to do clean builds each time. Another was that I wanted multiple build targets (static libraries and executables) and I didn't like cluttering up the directory tree with a different subdirectory for every build target.

    Now, I'm okay with using command-line gdb in Cygwin on the unit test executables, but I wanted to present something more user-friendly to my coworkers so I sought to use CCS as a gdb front-end for graphical debugging. This is how I got it to work after much trial and error. As a side benefit, it's now possible to build and run the unit tests from CCS as well. Before doing these steps, it's useful to build all of the unit test targets and make sure you can use command-line gdb to debug the executables. Leave the executables in the directory tree before following these steps.

    1) Go to Windows > Preferences to tell CCS how to work with Cygwin for local builds:

    - In General > Capabilities, check the box for "CDT GDB Debugging" to unlock Eclipse's normal abilities to handle local builds.

    - In General C/C++ > Debug > Source Location Lookup: Add a "Path Mapping" to map "\cygdrive\c" to "C:\"

    2) We need to create a new project that is *not* a "CCS Project" so it will have the right configuration details.

    - File > New > Project... > C/C++ Makefile Project With Existing Code

    - Give the new project a name that is distinct from your original CCS project.

    - For the existing code location, browse to the project's Test subdirectory. Even though no souce code lives in here, it will put the project's .project and .cproject files here so they won't conflict with the original project.

    - For "Toolchain for Indexer Settings", uncheck the box below for "Show only available toolchains that support this platform" then select "Cygwin GCC."

    3) After creating the project, go to the new project's properties and make these changes:

    - In C/C++ Build's "Behavior" tab, set the make build targets to what they need to be for your makefile. If you have multiple build targets, choose one of them.

    - In C/C++ Build > Environment, make sure variable CYGWIN_HOME has the path to your cygwin home. For me it is C:\cygwin64.

    - In C/C++ Build > Settings, in the Binary Parsers tab, make sure "Cygwin PE Parser" is checked.

    - In C/C++ Build > Tool Chain Editor, the current toolchain should be "Cygwin GCC" and the current builder "Gnu Make Builder."

    - In Run/Debug Settings, create a new launch configuration. There will eventually be one launch configuration for each unit test executable, but we'll start with one; give it a name like the makefile target that creates the executable. In the Main tab, for "C/C++ Application" click "Browse" and browse to a unit test executable you want to debug. Also in the Main tab, for "Build Configuration" check the box for "Select configuration using 'C/C++ Application'. On the Common tab, have the launch configuration display in the debug menu.

    4) Because the project's home directory is not the same as the source file location we need to tell the new debug configuration we just created where to find the source files.  We also have to tell it which debugger to use.

    - In Run > Debug Configurations..., find the launch configuration you just created, under C/C++ Application.

    - On your configuration's Debugger tab, set "GDB debugger" to point to the cygwin debugger. For me it's at C:\cygwin64\bin\gdb.exe. If you have a .gdbinit file, point to it here, but if you don't then ignore it.

    - On your configuration's Source tab, add a source lookup path. Choose "Project - Path relative to Source Folders", click OK, then choose the original CCS project containing your source code.

    After doing this, when I started up a debug session, it would start at the entry point for the unit test framework. I could open up any source file in the unit test execuable, right click on a line, and choose "Run to Line" to begin stepping through code.

    I hope this helps someone!

    Jeanne