Developer forums (C::B DEVELOPMENT STRICTLY!) > Development
Splitting debugger in two - specific debugger and common GUI
oBFusCATed:
Wait if you don't want to the the work twice, but how much I can't tell you...
BTW: I don't use remote debugging, so I do modify it only when someone ask for something to be added or fixed.
--- Quote from: cbexaminr on February 09, 2011, 07:48:52 pm ---(somewhat aisde -
Regarding your suggestion elsewhere of using dummy or makefile projects to support these functionalities, they are "clunky" in regard to my anticipated usage patterns, a)either by cluttering my environment with otherwise useless projects, or b) requiring additional keystrokes to regularly access/change (remote) debugging info in a project configuration that may be opened multiple times simultaneously (with multiple codeblock instances) to explore issues that could occur on multiple nodes each running one/more identical concurrent application instance(s) of that (currently non-)codeblocks project in a multi-node test environment.
--- End quote ---
This could be done by adding a way to have multiple remote debugging settings and a way to easily switch between them.
So it seems that you're using C::B as debugger wrapper and it is not a wrapper, it is an IDE -> so projects are first class citizens here.
There is single file compilation, but it is for students learning to program and no debugging there, too.
--- Quote from: cbexaminr on February 09, 2011, 07:48:52 pm ---Perhaps also worth mentioning, supporting multiple debug instances of the same application/project, with both/either remote and local instances, would support this use case as well, but I'm guessing, without trying [since there seems to be possibility of only one remote debugging info instance per project] that this is not currently supported.)
--- End quote ---
GDB doesn't support multiple instances at the moment, so no such support is planned. GDB is going to support it someday then we will done something about it.
Implementing in C::B will be too hard and too unreliable, probably, I've not tried it...
Stay tuned... 8)
dmoore:
--- Quote from: oBFusCATed on February 09, 2011, 08:37:31 am ---
--- Quote ---2. I noticed the the GDB_MI plugin was using some sort of smart pointer to store the breakpoint class instances (with the breakpoint class itself defined in the SDK). I would have thought the framework would provide the container classes...
--- End quote ---
Most of the time the plugin is the owner of the data and then the GUI classes query the debugger for this data, so they can display it in some way.
Probably this is not the best design, but I wanted to change as little as possible and also to minimize the copying of data.
--- End quote ---
Seems like a simple container defined in DebuggerManager.h (or wherever cbBreakpoint is defined) could take care of this:
--- Code: ---class BreakpointList
{
cbBreakpoint *operator[](...); //array style access
int GetCount(); //returns number of breakpoints
cbBreakpoint *Add(file, line); //returns NULL if request invalid
bool Remove(cbBreakpoint *); //returns true if successful
int Find(cbBreakpoint *); //find index of breakpoint
void RemoveAll();
}
--- End code ---
This way, implementation details like smartpointers can be hidden away from the user. Potentially useful features, such as sorting of breakpoints could also be implemented in this class. (Users with advanced needs can obviously still roll their own).
cbexaminr:
--- Quote from: oBFusCATed on February 09, 2011, 10:04:51 pm ---GDB doesn't support multiple instances at the moment, so no such support is planned. GDB is going to support it
--- End quote ---
GDB doesn't need to support multiple directly, since multiple instances of GDB can be invoked.
That is already done (by me at least), when codeblocks is used to debug itself, with the debugged codeblocks debugging yet another project/program.
The issue, or situation, I was outlining, is more related to having a possible need to have the same project open in more than one instance of codeblocks, assuming a user were forced to use a project to support debugging their application, but they need to debug multiple, possibly coordinating/cooperating instances of the target application.
[edit]Alternatively, the project may be open in only one codeblocks, but with other codeblocks instances debugging via the Debug external program functionality.
oBFusCATed:
dmoore: probably it could be done this way, write it down in you nodes file and go on, later we can modify it, if you still think it is good thing. By the way smart pointer usage is a bit broken,
because AddBreakpoint should return the smart pointer, not the pointee...I've added a TODO to look at it.
cbexaminr: The problem is with the synchronisation of the two+ instances and I think GDB could do it better, because they are closer to the OS.
The debugger in VS 2005+ does this pretty well...
Also it will make C::B's code way harder to read and write.
--- Quote from: cbexaminr on February 09, 2011, 10:20:13 pm ---[edit]Alternatively, the project may be open in only one codeblocks, but with other codeblocks instances debugging via the Debug external program functionality.
--- End quote ---
You can open the project in many instances of C::B and use attach to process, the remote case won't work probably.
dmoore:
--- Quote from: oBFusCATed on February 09, 2011, 11:49:32 pm ---dmoore: probably it could be done this way, write it down in you nodes file and go on, later we can modify it, if you still think it is good thing. By the way smart pointer usage is a bit broken,
because AddBreakpoint should return the smart pointer, not the pointee...I've added a TODO to look at it.
--- End quote ---
I thought that there might have been an issue with shared_pointer usage but wasn't familiar enough to be sure. I wonder whether you really need them at all. Is there really that much of a cost to copy the breakpoint data?
If sharepointers are your preferred solution then I guess you should be doing something like:
--- Code: ---struct cbBreakpointInternal
{
enum Type
{
Code,
Data
};
wxString m_filename;
wxString m_condition;
int m_line;
int m_ignoreCount;
Type m_type;
bool m_enabled;
bool m_useIgnoreCount;
bool m_useCondition;
wxString m_dataExpression;
bool m_breakOnRead;
bool m_breakOnWrite;
};
class cbBreakpoint
{
public:
cbBreakpoint();
cbBreakpoint(const wxString &filename, int line);
cbBreakpoint(const wxString &dataExpression, bool breakOnRead, bool breakOnWrite);
void SetLine(int line);
void SetCondition(wxString const &condition);
void SetIgnoreCount(int count);
void SetEnabled(bool flag);
void SetUseIgnoreCount(bool flag);
void SetUseCondition(bool flag);
const wxString & GetFilename() const;
const wxString & GetCondition() const;
int GetLine() const;
int GetIgnoreCount() const;
Type GetType() const;
bool IsEnabled() const;
bool UseIgnoreCount() const;
bool UseCondition() const;
const wxString& GetDataExpression() const;
bool GetBreakOnRead() const;
bool GetBreakOnWrite() const;
private:
shared_pointer<cbBreakpointInternal> ptr;
}
class BreakpointList
{
cbBreakpoint operator[](...); //array style access
int GetCount(); //returns number of breakpoints
cbBreakpoint Add(file, line); //returns NULL if request invalid
bool Remove(cbBreakpoint); //returns true if successful
int Find(cbBreakpoint); //find index of breakpoint
void RemoveAll();
}
--- End code ---
then the framework would work with copies of cbBreakpoint rather than (cbBreakpoint *)
Navigation
[0] Message Index
[#] Next page
[*] Previous page
Go to full version