Re: [beagleboard] recommendation for a symbolic debugger

[John Syne]

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




> On Aug 5, 2017, at 9:44 AM, clarkbriggs...@gmail.com wrote:
> 
> 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
 

https://training.ti.com/search-catalog/field_language/EN/categories/products?keyword_op=AND=CCS%20linux==
 

http://processors.wiki.ti.com/index.php/Linux_Debug_in_CCSv5 



> 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 Tuesday, August 1, 2017 at 2:24:49 PM UTC-7, john3909 wrote:
> You need arm-linux-gnueabihf-gdb and it needs to be the same as your compiler 
> version used to build your executable. 
> 
> Regards,
> John
> 
> 
> 
> 
>> On Aug 1, 2017, at 1:44 PM, clarkbr...@gmail.com  wrote:
>> 
>> 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 

Re: [beagleboard] recommendation for a symbolic debugger

[clarkbriggs101]

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 Tuesday, August 1, 2017 at 2:24:49 PM UTC-7, john3909 wrote:
>
> You need arm-linux-gnueabihf-gdb and it needs to be the same as your 
> compiler version used to build your executable. 
>
> Regards,
> John
>
>
>
>
> On Aug 1, 2017, at 1:44 PM, clarkbr...@gmail.com  wrote:
>
> 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
>
> On Thursday, July 27, 2017 at 4:14:58 PM UTC-7, William Hermans wrote:
>
>>
>>
>> On Thu, Jul 27, 2017 at 4:13 PM, William Hermans  
>> wrote:
>>
>>> 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. 
>>
>>
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/fa591c36-14bb-4237-8286-0076e36c4407%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You 

Re: [beagleboard] recommendation for a symbolic debugger

[John Syne]

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

Regards,
John




> On Aug 1, 2017, at 1:44 PM, clarkbriggs...@gmail.com wrote:
> 
> 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
> 
> On Thursday, July 27, 2017 at 4:14:58 PM UTC-7, William Hermans wrote:
> 
> 
> On Thu, Jul 27, 2017 at 4:13 PM, William Hermans  > wrote:
> 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. 
> 
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/fa591c36-14bb-4237-8286-0076e36c4407%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/587433A3-9E03-428E-A642-A003BB9EF79D%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] recommendation for a symbolic debugger

[clarkbriggs101]

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

On Thursday, July 27, 2017 at 4:14:58 PM UTC-7, William Hermans wrote:

>
>
> On Thu, Jul 27, 2017 at 4:13 PM, William Hermans  > wrote:
>
>> 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. 
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/fa591c36-14bb-4237-8286-0076e36c4407%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] recommendation for a symbolic debugger

[William Hermans]

On Thu, Jul 27, 2017 at 4:13 PM, William Hermans  wrote:

> 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.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORoA%3D5HscShmCFzV0beyQnqnRnE1SZrQPy2DfGj3fA8cPA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] recommendation for a symbolic debugger

[William Hermans]

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.

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/CALHSORrj%3D7YCkk7f0ipJ2QyQ1P%3DUBRtT-h-4qrXuTopcLMnbOA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] recommendation for a symbolic debugger

[clarkbriggs101]

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

On Wednesday, July 26, 2017 at 4:57:41 PM UTC-7, john3909 wrote:

> 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
>
>
>
>
> On Jul 26, 2017, at 4:34 PM, clarkbr...@gmail.com  wrote:
>
> 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 s much stuff that rebuilding would 
> be a set back.
> So what to do?
> Thanks,
> Clark
>
> -- 
> For more options, visit http://beagleboard.org/discuss
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard...@googlegroups.com .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/08df6016-8563-4d7a-98be-1feffb97e20a%40googlegroups.com
>  
> 
> .
> For more options, visit https://groups.google.com/d/optout.
>
>
>

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/6feb4433-64ca-488a-94da-7859f82a6442%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [beagleboard] recommendation for a symbolic debugger

[John Syne]

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




> On Jul 26, 2017, at 4:34 PM, clarkbriggs...@gmail.com wrote:
> 
> 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 s much stuff that rebuilding would be a set 
> back.
> So what to do?
> Thanks,
> Clark
> 
> -- 
> For more options, visit http://beagleboard.org/discuss 
> 
> --- 
> You received this message because you are subscribed to the Google Groups 
> "BeagleBoard" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to beagleboard+unsubscr...@googlegroups.com 
> .
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/beagleboard/08df6016-8563-4d7a-98be-1feffb97e20a%40googlegroups.com
>  
> .
> For more options, visit https://groups.google.com/d/optout 
> .

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/C678A9E7-E9E4-4D09-9DAB-CA459FDE0265%40gmail.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] recommendation for a symbolic debugger

[clarkbriggs101]

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 s much stuff that rebuilding would 
be a set back.
So what to do?
Thanks,
Clark

-- 
For more options, visit http://beagleboard.org/discuss
--- 
You received this message because you are subscribed to the Google Groups 
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/08df6016-8563-4d7a-98be-1feffb97e20a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.