[PATCH] Little debuggergdb refactoring

Discussion about CodeLite development process and patches
batt
CodeLite Curious
Posts: 7
Joined: Sat Dec 06, 2008 3:14 am
Contact:

[PATCH] Little debuggergdb refactoring

Post by batt » Sat Dec 06, 2008 5:58 pm

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
You do not have the required permissions to view the files attached to this post.

User avatar
eranif
CodeLite Plugin
Posts: 5982
Joined: Wed Feb 06, 2008 9:29 pm
Genuine User: Yes
IDE Question: C++
Contact:

Re: [PATCH] Little debuggergdb refactoring

Post by eranif » Sun Dec 07, 2008 12:09 am

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
Make sure you have read the HOW TO POST thread

batt
CodeLite Curious
Posts: 7
Joined: Sat Dec 06, 2008 3:14 am
Contact:

Re: [PATCH] Little debuggergdb refactoring

Post by batt » Sun Dec 07, 2008 2:46 pm

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

User avatar
eranif
CodeLite Plugin
Posts: 5982
Joined: Wed Feb 06, 2008 9:29 pm
Genuine User: Yes
IDE Question: C++
Contact:

Re: [PATCH] Little debuggergdb refactoring

Post by eranif » Sun Dec 07, 2008 3:31 pm

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
Make sure you have read the HOW TO POST thread

sdolim
CodeLite Veteran
Posts: 69
Joined: Fri Oct 24, 2008 10:29 pm
Contact:

Re: [PATCH] Little debuggergdb refactoring

Post by sdolim » Mon Dec 08, 2008 12:32 pm

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.

batt
CodeLite Curious
Posts: 7
Joined: Sat Dec 06, 2008 3:14 am
Contact:

Re: [PATCH] Little debuggergdb refactoring

Post by batt » Wed Dec 10, 2008 12:25 am

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?

sdolim
CodeLite Veteran
Posts: 69
Joined: Fri Oct 24, 2008 10:29 pm
Contact:

Re: [PATCH] Little debuggergdb refactoring

Post by sdolim » Wed Dec 10, 2008 2:06 am

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 :D

User avatar
eranif
CodeLite Plugin
Posts: 5982
Joined: Wed Feb 06, 2008 9:29 pm
Genuine User: Yes
IDE Question: C++
Contact:

Re: [PATCH] Little debuggergdb refactoring

Post by eranif » Wed Dec 10, 2008 11:52 am

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 :D
Sounds about right.

Eran
Make sure you have read the HOW TO POST thread

User avatar
eranif
CodeLite Plugin
Posts: 5982
Joined: Wed Feb 06, 2008 9:29 pm
Genuine User: Yes
IDE Question: C++
Contact:

Re: [PATCH] Little debuggergdb refactoring

Post by eranif » Wed Dec 10, 2008 7:07 pm

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
Make sure you have read the HOW TO POST thread

batt
CodeLite Curious
Posts: 7
Joined: Sat Dec 06, 2008 3:14 am
Contact:

Re: [PATCH] Little debuggergdb refactoring

Post by batt » Mon Dec 15, 2008 11:40 pm

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

Post Reply