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.

Linux Aware Debugging CCSv5 GDB server GDB host issue

When I try to connect to the target using CCSv5 GDB debugger, I get the error:

Error in final launch sequence
Failed to execute MI command:
-target-select remote 10.100.10.206:5000
Error message from debugger back end:
Malformed packet(b) (missing colon): ore:0;
Packet: 'T050b:00000000;0d:e0ad90be;

0f:f0070040;thread:499;core:0;'

Malformed packet(b) (missing colon): ore:0;
Packet: 'T050b:00000000;0d:e0ad90be;0f:f0070040;thread:499;core:0;'

My configuration is:
 
   Beagleboard Angstrom/2.6.32 - unmodified Beagleboard-Xm delivery

  GNU gdbserver (GDB) 7.2
  Copyright (C) 2010 Free Software Foundation, Inc.
  gdbserver is free software, covered by the GNU General Public License.
  This gdbserver was configured as "arm-angstrom-linux-gnueabi"

unmodified CodeSourcery distribution.
GNU gdb (Sourcery G++ Lite 2009q1-203) 6.8.50.20081022-cvs
 Copyright (C) 2008 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-linux-gnu --target=arm-none-linux-gnueabi".

Is this error due to the differences between gdb and server configurations?

Is there a relevant link which explains how to deal with this issue? My application so far has been an unmodified Beagle-Xm  with Code Composer Studio ,  Version: N201105110900, Linux Ubuntu 10.4.  Hopefully, the method for resolving this has been documented and posted.

 Thanks
  • Hi,

    I searched around on the internet and found a similar issue reported here. Although the thread is not conclusive, you may be right: the differences in the configurations may be affecting the command syntax between the host and the target.

    The closest page we have about the process of building gdb is here - a requirement due to the absence of gdb and gdbserver in older DVSDK versions. However I am not aware of step-by-step instructions for the Angstrom distribution - the only thread I found is here. You may want to search the web to get the exact options to cross-compile gdb and gdbserver.

    As you can imagine, it is very difficult to support the multitude of open source software and linux distributions available, therefore most of this information will have to be found directly off the web.

    Hope this helps,

    Rafael

     

  • I successfully connected and single stepped using CCSv5 and the Angstrom distribution shipping on the Beagleboard-Xm with a Ubuntu host. Downloading the latest CodeSourcery Lite distribution and installing in a manner that allowed both the host and the target to use the same distribution for gdb (host) and gdbserver (remote) enabled the two entities to connect.

     I installed the G++ tools for ARM GNU/LINUX from http://www.codesourcery.com/sgpp/lite/arm/portal/release1803 within the exported directory of the host.

     On the host side, I pointed the gdb debugger within CCS to point at the gdb executable within the shared, exported, directory.

     On the target side (remote), I invoked the gdb server within the same shared, exported, directory.

     The CCSv5 debugger connected and I was able to single step the program

  • Were you able to get source level debugging working?

    My code ran fine building in (VMWare) Ubuntu Linux and File->New Makefile Project with Existing Code into a WinXP CCSv5.1.

    But the C source did not follow even after  a WinXP .gdbinit. 

    I matched my make file to the one in: http://processors.wiki.ti.com/index.php/CCSv5_Advanced_Workshop

    The sample code linuxapp.zip from above worked great.  But the Source tab from slide 131 of CCSv5_AdvancedWorkshop.pdf did not look like the path was correct.

    Any idea how the linuxapp.zip was built?

    The error I would get is:

    warning: Unable to find dynamic linker breakpoint function.
    GDB will be unable to debug shared library initializers
    and track explicitly loaded dynamic code.
    No symbol table is loaded.  Use the "file" command.
    Cannot access memory at address 0x0
    warning: Could not load shared library symbols for 3 libraries, e.g. /lib/libgcc_s.so.1.
    Use the "info sharedlibrary" command to see the complete listing.
    Do you need "set solib-search-path" or "set sysroot"?

     

  • Turns out linuxapp.zip was built in Linux CCSv5 (any make files are spurious).  I was able to build in WinXP CCSv5 and get Source Level Debugging.

    The key (but VERY) subtle nuance to getting this to work is on Neon_gdb_ccsv5_Source_Lookup_Path.jpg (attached) that shows the highlighted "Default" of the source directory. 

    For the last couple days the "+" would not expand.  But was able to get it working this morning by building a CCS project with GCC/Codesourcery in WinXP following:
    http://processors.wiki.ti.com/index.php/How_to_create_GCC_projects_in_CCSv5#Creating_a_Linux_GCC_project_in_Windows_hosted_CCSv5