CodeLite IDE

I am trying to use CodeLite to debug embedded targets that use custom build files and a custom gdb server without success (for now).
I was looking at the debugger code (Debugger/debuggergdb.cpp) to find why and I found that the there is code duplication in the DbgGdb::Start() functions.

There are some difference if the gdb is started with a pid or with a file to execute but I am not sure that those differences are really needed. Maybe they came out because you forgot to fix one of the 2 functions that start gdb.

However I factorized the two functions in one and added some 'if' to handle the differences.
Here is the patch, hoping that will be useful.

Francesco Sacchi

batt wrote:I am trying to use CodeLite to debug embedded targets that use custom build files and a custom gdb server without success (for now)

Have u looked under project settings (project context menu) settings -> debugger ?
You can set the port/tty of the gdbserver + specify some command to be sent to the debugger *before* the 'run' command

Eran

eranif wrote:

batt wrote:I am trying to use CodeLite to debug embedded targets that use custom build files and a custom gdb server without success (for now)

Have u looked under project settings (project context menu) settings -> debugger ?
You can set the port/tty of the gdbserver + specify some command to be sent to the debugger *before* the 'run' command

Yes, I've already done this but it doesn't work. However I didn't experiment very much and I can't try right now because my boards are in the office, I will look again on Tuesday.
However what do you think about the patch?
It simplifies the code and make it less bug prone.

Francesco Sacchi

I am currently on a vacation with limited internet access, so I will have a look at it once I will get back (which should be on Wednesday), unless sdolim is wiling to have a look and approve it.

Eran

This is an area of the code I'm not too familiar with. I'd rather wait for Eran to have a look at it, unless it fixes something important.

eranif wrote:

batt wrote:I am trying to use CodeLite to debug embedded targets that use custom build files and a custom gdb server without success (for now)

Have u looked under project settings (project context menu) settings -> debugger ?
You can set the port/tty of the gdbserver + specify some command to be sent to the debugger *before* the 'run' command

OK, I experimented a bit.
The debugging doesn't work because I need to send custom gdb commands *after* the target remote connection is created and not before.
What embedded developers need would be another field for entering gdb commands to be sent *after* the 'run' (aka remote target connection).
I will try to create a patch, do you have any advices for doing this?

There's a class called DbgCmdHandlerRemoteDebugging that responds to the output of the "target remote" command. Currently it just passes the text back to the Manager::UpdateAddLine() method. So here's what I would do:

- In BuildConfig, add a method GetDebuggerRemoteConnectionCmds() similar to the existing GetDebuggerStartupCmds(). Also add a setter, and patch the serialization so that the value is persisted in the project settings file.
- Add a box in ProjectSettingsDlg to edit the remote connection cmds, similar to the way the existing startup cmds editor works.
- Add a pure virtual method "IDebuggerObserver::UpdateRemoteConnection(const wxString &line, bool successful)".
- Have DbgCmdHandlerRemoteDebugging::ProcessOutput() parse the output and call m_observer->UpdateRemoteConnection() instead of m_observer->UpdateAddLine(). (This assumes you only need the one line of output to determine success or failure.)
- In Manager, add an implementation of UpdateRemoteConnection(). First have it call UpdateAddLine(). Then, if successful is true, have it get the remote connection cmds from the build config, and then call IDebugger::ExecuteCmd() on each one.

Eran, please correct any obvious (or not) errors in the above suggestions

sdolim wrote:There's a class called DbgCmdHandlerRemoteDebugging that responds to the output of the "target remote" command. Currently it just passes the text back to the Manager::UpdateAddLine() method. So here's what I would do:

- In BuildConfig, add a method GetDebuggerRemoteConnectionCmds() similar to the existing GetDebuggerStartupCmds(). Also add a setter, and patch the serialization so that the value is persisted in the project settings file.
- Add a box in ProjectSettingsDlg to edit the remote connection cmds, similar to the way the existing startup cmds editor works.
- Add a pure virtual method "IDebuggerObserver::UpdateRemoteConnection(const wxString &line, bool successful)".
- Have DbgCmdHandlerRemoteDebugging::ProcessOutput() parse the output and call m_observer->UpdateRemoteConnection() instead of m_observer->UpdateAddLine(). (This assumes you only need the one line of output to determine success or failure.)
- In Manager, add an implementation of UpdateRemoteConnection(). First have it call UpdateAddLine(). Then, if successful is true, have it get the remote connection cmds from the build config, and then call IDebugger::ExecuteCmd() on each one.

Eran, please correct any obvious (or not) errors in the above suggestions

Sounds about right.

Eran

I committed a fix that allows user to send command to the gdbserver after target remote command and just before the 'continue' command.
These commands can be set from 'project settings -> debugger'
Revision 2514.

Eran

eranif wrote:I committed a fix that allows user to send command to the gdbserver after target remote command and just before the 'continue' command.
These commands can be set from 'project settings -> debugger'
Revision 2514.

Thank you Eran!
I was unable to work on the patch by myself due to a health problem (nothing serious), now that I am coming back to work I see that you have already done a good job!
Thank you again, my team and I can finally settle down on a great IDE!

Bye
Francesco
http://www.bertos.org