I'm poking at codelite to try and get it to work with gdb + PEMicro's GDBServer on a Freescale KL15 Arm processor.
So far I can manually run GDB from the command line and it works. But I have a few issue with codelite.
One question is, the version of gdb I have doesn't have support for python? I'm assuming this just means no pretty printing, or are there other issues?
Second question, when trying to get codelite to work I had to add under project settings -> debugger -> startup command 'file ../repeat_main_rev1.elf' I think this is an issue because codelite thinks repeat_main_rev1.elf is under ./Debug. In my case it's one step lower down.
Third: Doing that and checking the box under settings -> gdb settings -> [X] automatically set breakpoint at main. When I do that and start debugging the program then loads and I get a breakpoint. However trying to 'pause debugger' seems to do nothing. (the processor doesn't halt, and the GDB Server doesn't report anything If I hit 'stop debugger' then the session ends.
Any help that can be provided or comments while be appreciated.
Issues with remote debugging with gdb
-
- CodeLite Expert
- Posts: 167
- Joined: Fri Jul 22, 2011 5:32 am
- Genuine User: Yes
- IDE Question: C++
- Contact:
-
- CodeLite Expert
- Posts: 167
- Joined: Fri Jul 22, 2011 5:32 am
- Genuine User: Yes
- IDE Question: C++
- Contact:
Re: Issues with remote debugging with gdb
Did find that when debugging, if you change the link target codelite doesn't appear to pick it up and assumes the program to debug is named $(IntermediateDirectory)/$(ProjectName)
I changed things back to defaults and now GDB doesn't complain about the missing executable.
I think this is a bug/feature request.
I changed things back to defaults and now GDB doesn't complain about the missing executable.
I think this is a bug/feature request.
-
- CodeLite Expert
- Posts: 167
- Joined: Fri Jul 22, 2011 5:32 am
- Genuine User: Yes
- IDE Question: C++
- Contact:
Re: Issues with remote debugging with gdb
Also, looked more closely to the 'remote debugging patch someone submitted. Looks like it tries to address this issue
Will try and patch codelite and try...
Will try and patch codelite and try...
- eranif
- CodeLite Plugin
- Posts: 6375
- Joined: Wed Feb 06, 2008 9:29 pm
- Genuine User: Yes
- IDE Question: C++
- Contact:
Re: Issues with remote debugging with gdb
Yes, no pretty printing onlyGibbon1 wrote:One question is, the version of gdb I have doesn't have support for python? I'm assuming this just means no pretty printing, or are there other issues?
Why don't you use the 'basic' options under project settings->common settings->general->executionGibbon1 wrote:Second question, when trying to get codelite to work I had to add under project settings -> debugger -> startup command 'file ../repeat_main_rev1.elf' I think this is an issue because codelite thinks repeat_main_rev1.elf is under ./Debug. In my case it's one step lower down.
there you can:
- set the executable to debug
- set the working directory for gdb
This issue was already addressed in this commit (post codelite 6.1.1): https://github.com/eranif/codelite/comm ... 67145b3d64Gibbon1 wrote:When I do that and start debugging the program then loads and I get a breakpoint. However trying to 'pause debugger' seems to do nothing
Eran
Make sure you have read the HOW TO POST thread
-
- CodeLite Expert
- Posts: 167
- Joined: Fri Jul 22, 2011 5:32 am
- Genuine User: Yes
- IDE Question: C++
- Contact:
Re: Issues with remote debugging with gdb
Tried building codelite (it complains about my older version of gcc 4.7.x vs 4.8.x (whatherewver)
But it appears to build okay, however when I ran update.bat I got a "The systems cannot find the file specified" for the following line
copy codelite-clang.exe "%TARGET_DIR%\CodeLite\" /Y
Looking there is no codelite-clang.exe in the Runtime folder. Hmmm.... codelite does start up.
And um... pause now works!!!!!
HFS!!!!!!!!!!!!!
But it appears to build okay, however when I ran update.bat I got a "The systems cannot find the file specified" for the following line
copy codelite-clang.exe "%TARGET_DIR%\CodeLite\" /Y
Looking there is no codelite-clang.exe in the Runtime folder. Hmmm.... codelite does start up.
And um... pause now works!!!!!
HFS!!!!!!!!!!!!!
-
- CodeLite Expert
- Posts: 167
- Joined: Fri Jul 22, 2011 5:32 am
- Genuine User: Yes
- IDE Question: C++
- Contact:
Re: Issues with remote debugging with gdb
After using this a bit, seems like there are some issues with disconnecting from the GDBServer. Some of which are due to PEMicro's GDBServer being a bit finicky.
One thing I have seen is sometimes when you hit Debugger -> stop debugger the gdb window gets left open. Closing it manually causes codelite to crash/exit.
I'm kind of curious, there are a whole host of remote debugging scenario's, one wonders how much of a thicket that is to support.
One potentially interesting one is debugging programs on say a Beagle Board where you have
Codelite on WinX -> pipe -> GDB on WinX -> TCP -> linux + gdb server -> program
Which is different than what I'm doing
Codelight -> pipe -> GDB -> localhost -> GDBServer (PEMicro) -> USB -> PEMultilink ICE -> SWD -> KL15 ARM -> Program
I think the original patach the guy was using
Codelight -> pipe -> GDB -> localhost -> GDBServer (Segger) -> USB -> Segger Jlink -> SWD -> ??? ARM -> Firmware
There is also openOCD which sits between GDB and the ICE.
One thing I have seen is sometimes when you hit Debugger -> stop debugger the gdb window gets left open. Closing it manually causes codelite to crash/exit.
I'm kind of curious, there are a whole host of remote debugging scenario's, one wonders how much of a thicket that is to support.
One potentially interesting one is debugging programs on say a Beagle Board where you have
Codelite on WinX -> pipe -> GDB on WinX -> TCP -> linux + gdb server -> program
Which is different than what I'm doing
Codelight -> pipe -> GDB -> localhost -> GDBServer (PEMicro) -> USB -> PEMultilink ICE -> SWD -> KL15 ARM -> Program
I think the original patach the guy was using
Codelight -> pipe -> GDB -> localhost -> GDBServer (Segger) -> USB -> Segger Jlink -> SWD -> ??? ARM -> Firmware
There is also openOCD which sits between GDB and the ICE.