recommendation for a symbolic debugger

I really need to have a symbolic interface to gdb running on my BBBs. Here is my situation.
I keep build copies of the software on the BBB and compile them on the BBB.
I edit them on my PC, keeping the masters in a local repo. I manually move them over after editing to compile them on the BBB.
I have tried debugging on the BBB with gdb and its command line interface but the code has gotten too complicated nowadays.
I am running the 2017-03-19 image with updates. I am concerned about the file space remaining on the BBB so I don’t want a big app on the BBB.
I can do X to my desktop, so an X frontend to dbg seems like the best answer.
In other situations, I have used Eclipse CDT on my dev station (that was a Ubuntu box) but cross compiling and remote debugging were a problem. I ended up pushing the sources over and compiling over on the BBB and never remote debugged.
Now I have a Windows dev station and I could put Eclipse on it, but things like cross compiling would be a disaster.
I push the BBB pretty hard with my app. The BBB is only a single processor. Whatever the front end it shouldn’t take a lot of cpu. I guess during debugging sessions, the cpu load is excusable tho.
I don’t think the file space for putting Eclipse CDT on the BBB is affordable, otherwise I like running Eclipse on the BBB. I can teach Eclipse where my repo is. I could run it via X from my PC.
I could rebuild the bots but use a big SD card so file space isn’t a problem. I guess I haven’t accreted soooo much stuff that rebuilding would be a set back.
So what to do?
Thanks,
Clark

Are you debugging user space app or kernel code like drivers, kernel modules, etc?

If you are debugging user space app, you have two solutions:1) use gdbserver on your BBB and Code Composer Studio (CCSV7) or Eclipse on your host, which uses gdb for debugging. You will need your BBB source code on your host. I recommend that you use NFS to host your BBB rootfs on your host machine.
2) use USB200 JTAG debugger and use CCSV7 for debugging.

For kernel code debugging, you can use 2) above, but the debugging is limited because CCSV7 isn’t kernel aware.

Regards,
John

John,
Thanks a lot.
I am debugging a user space app.
I guess I didn’t realize I could use Eclipse on my host and debug on the target without the binaries on the host. I do have the sources on my host anyway.
I have never heard of CCSV7 but a quick look at http://www.ti.com/tool/ccstudio is attractive. I’ll check it out.
Thanks,
Clark

This is probably the best guide you’re going to find on the subject.

https://www.youtube.com/watch?v=T9yFyWsyyGk

Never used it myself( I do not cross compile ), but I’m confident DR Molly’s instructions work.

Just in case it's not clear, R Molly shows how to setup remote debugging
towards the end I think. Been a while since I've watched this.

William etal,
Pointing to Molloy was a good hint. I watched him do it and around minute 31 he starts into remote debugging. He uses Eclipse and some cross tool chain, but I didn’t watch that. I am using the TI CCS v7.2 on Windows 7x64 which is Eclipse based, but not cross compiling with their included tools.
My configuration is somewhat different from Molloy’s. He is cross compiling so the sources AND the binary are present on the dev machine with Eclipse. I have only the sources on my dev machine since I compile on the BBB.
Issue 1. When creating a remote debug configuration in CCS/Eclipse the Main tab field “C/C++ Application:” apparently wants the local binary on the dev machine. It isn’t happy without it and won’t move forward at all. If I drag the binary from the BBB back to the dev workspace and point at it, it will go on.
What is the correct way to configure this environment (source and dbg on Win dev host; source, binaries and gdbserver on BBB)?
Issue 2. So with a copy of the application binary on the dev host, launching a remote debugging session leads to a gripe from the gdbserver about not understanding the MI command list-features. The console shows the connection on the BBB target successfully launches gdbserver with the configured port, the absolute path to the executable and the arguments. After the “listening on port 2345” echo it terminates with the gripe about the MI command.
Groping der google suggests this is often due to not having the correct architecture gdb on the dev host selected. When installing CCSv7 I picked only the arm tools for the AM33xx family processor. In the debug configuration debugger tab main tab GDB debugger is the default setting “gdb”. There is a Browse button to go looking through the installed ti/ccsv7/tools/compiler, but the only gdb in the TI tools I can find is C:\ti\ccsv7\tools\compiler\gcc-arm-none-eabi-6-2017-q1-update\bin\arm-none-eabi-gdb.exe. that gdb echoes as it starts “This GDB was configured as “–host=i686-w64-mingw32 --target=arm-none-eabi”.” then warns “warning: A handler for the OS ABI “GNU/Linux” is not built into this configuration of GDB. Attempting to continue with the default arm settings.” It then quits with a complaint that no source was available.
Maybe this is really a TI CCS specific setting. Earlier John pointed to CCS so maybe he can provide some direction.
Thanks,
Hugh

You need arm-linux-gnueabihf-gdb and it needs to be the same as your compiler version used to build your executable.

Regards,
John

John,
Thanks. It does sound like you know the TI CCS stuff. While the TI market place exposed several high level products, I can’t figure out how to drill down to the compiler. In particular, I think I installed for the AM33xx BBB processor when I first put CCS in, but can’t find any trace of the processor family in the configuration. Further, I don’t find any settings for the target OS. I am using CCS on Windows and targeting Debian on the BBB.
Like I said, this is a complex and maybe unusual configuration (source debugging remotely but compiling natively on the target), so I wanted to try a cross compile for helloworld.c but can’t find the TI compiler in the development environment. I figured if that worked, the right gdb would be there and I could try living with a (nicely set up by TI) cross development environment.
So…how to put just the right cross compiler in this existing CCS install?
Thanks,
Hugh/Clark

On Sat, 5 Aug 2017 09:44:51 -0700 (PDT),
clarkbriggs101@gmail.com declaimed the
following:

John,
Thanks. It does sound like you know the TI CCS stuff. While the TI market
place exposed several high level products, I can't figure out how to drill
down to the compiler. In particular, I think I installed for the AM33xx BBB
processor when I first put CCS in, but can't find any trace of the
processor family in the configuration. Further, I don't find any settings
for the target OS. I am using CCS on Windows and targeting Debian on the
BBB.

  Target processor, and thereby compiler, is specified in the New Project
page or via the Project properties page... I've not seen anything for OS
specific builds (granted, I've only done a cursory look just now -- my only
CCS experience has been a lesson book for TIVA and TI-RTOS).
BeagleBone-Black appears to be a predefined target.

  Have not seen anything for selecting debugger (I don't have any
hardware debuggers, other than that built into the TIVA launchpads).

  A quick glance appears to imply that the compiler toolchain is a
bare-metal/NoOS option.

I haven’t used CCS for several years as I use Lauterbach for all my linux kernel/driver debugging. However, I’ll try to remember how to everything you need. See inline comments:

Regards,
John

John,
Thanks. It does sound like you know the TI CCS stuff. While the TI market place exposed several high level products, I can’t figure out how to drill down to the compiler. In particular, I think I installed for the AM33xx BBB processor when I first put CCS in, but can’t find any trace of the processor family in the configuration. Further, I don’t find any settings for the target OS. I am using CCS on Windows and targeting Debian on the BBB.

Use CCS to create a new C/C++ Makefile project. On the project in the explorer panel, right click on the project name and select properties. I don’t recall the section, but you should see a section with environment variables, where you add:
CROSS_COMPILE=/arm-linux-gnueabihf-
ARCH=arm
Now in the explorer panel, add files/folders and then run “Build Project” (I think that is the name). You should see the result/errors of your build in the console window.

This might help:

https://training.ti.com/linux-board-porting-series-module-10-debugging-linux-kernel-jtag-ccs
[Videos | TI.com](Videos | TI.com linux&start=&end=)
http://processors.wiki.ti.com/index.php/Linux_Debug_in_CCSv5