Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: DoMeN on December 07, 2006, 03:49:00 pm

Title: debugging plugin
Post by: DoMeN on December 07, 2006, 03:49:00 pm

Hi,

I'm implementing hw breakpoints in C::B and it would save me lots of time if someone could tell me:

- Which function of debugging plugin is the top function that is connected to C::B and where in C::B it is called.
- Allso I would need to know which function does the drawing of the breakpoint circles and where is the mouse event function that calls the draw circle function.

thanks

Domen

Title: Re: debugging plugin
Post by: dje on December 07, 2006, 04:00:37 pm

Hi !!

Quote

- Allso I would need to know which function does the drawing of the breakpoint circles and where is the mouse event function that calls the draw circle function.

The cbEditor manages margin clicks events.
Let's have a look at :
void cbEditor::ToggleBreakpoint(int line, bool notifyDebugger)
and
void cbEditor::OnMarginClick(wxScintillaEvent& event)
in CodeBlocks\src\sdk\cbeditor.cpp

Dje

Title: Re: debugging plugin
Post by: dmoore on December 07, 2006, 04:20:35 pm

Quote from: DoMeN on December 07, 2006, 03:49:00 pm

- Which function of debugging plugin is the top function that is connected to C::B and where in C::B it is called.

not sure what you mean by "top function". base class?

look at debuggergdb.h in the src/plugins/debuggergdb folder - debuggergdb is inherited from a cbdebuggerplugin class that contains virtual overrides for handling add/remove breakpoints and syncing with editor changes. handlers for user requests to start, stop, move to the next instruction are also handled by this class (albeit delegated to other classes to do the actual work). when the plugin is initialized, the plugin mgr will call onAttach, so you could do some initialization here.

The best advice I can give you is to read through the debugger plugin's code and the relevant sdk code starting from the relevant event handlers. right click "find implementation of..." works like a charm

Quote

- Allso I would need to know which function does the drawing of the breakpoint circles and where is the mouse event function that calls the draw circle function.

good luck with this. As dje said, Breakpoint markings are handled by the cbEditor. You can get a handle to a particular editor window to pass it messages to add/remove breakpoints. AFAIK there is no way to customize the breakpoint tags without messing with the sdk, which you really don't want to do unless you do it in a sufficiently flexible and useful way that others would find it useful too. I think the big kahuna has plans to enhance the debugger portion of the sdk to make it a little more flexible. allowing for unique markers for different breakpoint types might be something you could request as part of this enhancement.

Title: Re: debugging plugin
Post by: Joerg on December 07, 2006, 05:22:16 pm

Quote from: DoMeN on December 07, 2006, 03:49:00 pm

I'm implementing hw breakpoints in C::B and ...

Ah, thats interesting.
I still wonder if C::B works for embedded debugging.
I have some success with ARM7 cross-compiling -debugging
with Eclipse,WinARM, OpenOCD.
I think Eclipse with Embedded CDT doesn't know also
about the two hardware breakpoints limit of JTAG (ARM7).
You just get errors if you try to assign more.
I think this is the current behavior of C::B ,too?
Greets,
Joerg

Title: Re: debugging plugin
Post by: DoMeN on December 08, 2006, 11:37:12 am

I just renamed break to hbreak and set a counter to prevent you from setting more HW breakpoints than the implementation allows and if you reach the maximum you have to clear a breakpoint to set a new one. I also had to change the output parsing a bit so that ti treats hbreak as a breakpoint. This works fine but I was told that we need HW and SW breakpoints and here I'm having some problems because they have to be different colors to destinguish between them and you have to be able to select which one of them you want to set.

EDIT: C::B doesnt support HW breakpoints: http://forums.codeblocks.org/index.php?topic=4642.0

Title: Re: debugging plugin
Post by: DoMeN on December 08, 2006, 11:38:11 am

Btw does annione know which part of the code sets the color of breakpoints to red ?

Title: Re: debugging plugin
Post by: dje on December 08, 2006, 11:47:43 am

Hi !!

codeblocks/sdk/cbeditor.cpp in void cbEditor::InternalSetEditorStyleBeforeFileOpen(cbStyledTextCtrl* control)

Code

control->MarkerSetBackground(BREAKPOINT_MARKER, wxColour(0xFF, 0x00, 0x00));

Dje

Title: Re: debugging plugin
Post by: DoMeN on December 11, 2006, 03:44:43 pm

I have a question for the C::B dev team.
thomas told me the reasons why you don't want to add hardware breakpoint support in the main release but why wouldn't it be acceptable to have a text box to write how manny HW breakpoints are supported on the platform you are debugging and a check box to indicate whether you want to activate HW breaks or not. Then, during the debugging, could choose between HW and SW breaks and you would have two different colors for e.g. red for SW and green for HW breaks and when you reach HW breaks limit you can't add a new one untill you unset a previous one.

I think that since everyone using the HW breaks allso knows how manny breakpoints HW debugging unit supports this would be a usefull feature and there wouldn't be anny problems with the ussage.

What do others think about this?

r. Domen

Title: Re: debugging plugin
Post by: Game_Ender on December 11, 2006, 06:33:40 pm

I think it would be better if the editor knew nothing of breakpoints at all.  After all its just an editor why couple it so closely to the debugger.  You should have the ability to draw little arbitrary objects in the margin, for which you can register event handlers.  The event handlers can be called whenever the any of the little widgets are left or right clicked, or the line they are on changes.  You will probably have to pass some kind of "MarginWidget" object to the cbEditor which encapsulates this functionality.

This would allow you to have custom breakpoints icons, or even to use the little side bar to show other information.  This other information could be code coverage markers, line coverage etc.  For all those who care, this is what Eclipse does (a UI whose flexibility we should strive for).

P.S.-  Has anyone seen the wxPython 2.7 wxAUI + FlatNotebook class/integration?  It gives you tear away tabs!  Hopefully this will be available/ported to C++ version of wxWidgets.

Title: Re: debugging plugin
Post by: DoMeN on December 12, 2006, 08:43:34 am

Yes I agree about this encapsulating object. I tried to change the cbEditor code as little as possible. I only added a new green colored breakpoint and if else statements to tel the cbEditor which of the two breaks should he draw. Then I added a variable to the debugger to indicate which type of breaks you want to use  and a function that you call from cbEditor to know there which break should be drawn.

The code isn't complete yet so I can't decide after the compile which breakpoint type should be used ( I don't have a dropdown list to select the type from). I'm allso not sure whether or not I will be able to continue because my boss told me that the changes were too extense and that I should somehow change our gdb so that it would first set all the HW breaks and then SW breaks so C::B wouldn't even see the difference. The problem with this approach is that you don't see whether you use HW or SW breakpoints so I think that this is somehow useless.

It would be werry helpfull for me if the main C::B release would have a way to choose between different breakpoints so where would it be the best place to write a feature request for

Quote

You will probably have to pass some kind of "MarginWidget" object to the cbEditor which encapsulates this functionality.

this wrapper object?

Title: Re: debugging plugin
Post by: Game_Ender on December 12, 2006, 09:35:19 pm

Make a post about it in this forum (seeing as how this an SDK issue not and General CB issue) and then post a feature request at berlios (http://developer.berlios.de/feature/?group_id=5358).  You could also to get a proof of concept patch as well.