Author Topic: Some thoughts on doing breakpoints persistent  (Read 42895 times)

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5913
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Some thoughts on doing breakpoints persistent
« on: June 16, 2009, 11:18:18 am »
UPDATED 2012-12-15: Patch was in https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=2775&group_id=5358
Some related discussion in Re: Splitting debugger in two - specific debugger and common GUI


Hi, all.

I'm thinking to save the breakpoints in  debuggergdb plugin. (I don't think I have the ability to do the whole job, just plan to do this .... :()
After reading the related source code, I think the best time to "load the breakpoints from a project" is in:

Code
void DebuggerGDB::OnProjectLoadingHook(cbProject* project, TiXmlElement* elem, bool loading)


I think both "breakpoints" list and "watch variables list" can be automatically saved to hard disk, and loaded when a project opened.

Also, we can take the source code from "browsetracker.cpp" as a reference (BrowseTracker plugin).
Code
// ----------------------------------------------------------------------------
void ProjectData::LoadLayout()
// ----------------------------------------------------------------------------
{
    // Load a layout file for this project
    #if defined(LOGGING)
    LOGIT( _T("ProjectData::LoadLayout()for[%s]"),m_ProjectFilename.c_str() );
    #endif

    if (m_ProjectFilename.IsEmpty())
        return ;

    wxFileName fname(m_ProjectFilename);
    fname.SetExt(_T("bmarks"));
    BrowseTrackerLayout layout( m_pCBProject );
    layout.Open(fname.GetFullPath(), m_FileBrowse_MarksArchive, m_FileBook_MarksArchive);
    m_bLayoutLoaded = true;
}
// ----------------------------------------------------------------------------
void ProjectData::SaveLayout()
// ----------------------------------------------------------------------------
{
    // Write a layout file for this project
    #if defined(LOGGING)
    LOGIT( _T("ProjectData::SAVELayout()") );
    #endif

    if (m_ProjectFilename.IsEmpty())
        return ;

    wxFileName fname(m_ProjectFilename);
    fname.SetExt(_T("bmarks"));
    BrowseTrackerLayout layout( m_pCBProject );
    ////DumpBrowse_Marks(wxT("BookMarks"));
    ////DumpBrowse_Marks(wxT("BrowseMarks"));
    layout.Save(fname.GetFullPath(), m_FileBrowse_MarksArchive, m_FileBook_MarksArchive);


    //// *Testing* See if cbEditor is actually there
    //EditorBase* eb = m_EditorBaseArray[1];
    //cbEditor* cbed = Manager::Get()->GetEditorManager()->GetBuiltinEditor(eb);
    //cbStyledTextCtrl* control = cbed->GetControl();
    //#if defined(LOGGING)
    //LOGIT( _T("eb[%p]cbed[%p]control[%p]"), eb, cbed, control );
    //#endif

    //// *Testing* Check against our array
    //eb = m_EditorBaseArray[1];
    //cbed = m_cbEditorArray[1];
    //control = m_cbSTCArray[1];
    //#if defined(LOGGING)
    //LOGIT( _T("eb[%p]cbed[%p]control[%p]"), eb, cbed, control );
    //#endif


}

But I can't determine which Event is good for loading breakpoints.

Code
// -- Project events
    // EVT_PROJECT_OPEN(       BrowseTracker::OnProjectOpened)
    Manager::Get()->RegisterEventSink(cbEVT_PROJECT_OPEN, new cbEventFunctor<BrowseTracker, CodeBlocksEvent>(this, &BrowseTracker::OnProjectOpened));
    // EVT_PROJECT_CLOSE(       BrowseTracker::OnProjectOpened)
    Manager::Get()->RegisterEventSink(cbEVT_PROJECT_CLOSE, new cbEventFunctor<BrowseTracker, CodeBlocksEvent>(this, &BrowseTracker::OnProjectClosing));

    // EVT_PROJECT_ACTIVATE(   BrowseTracker::OnProjectActivated)
    Manager::Get()->RegisterEventSink(cbEVT_PROJECT_ACTIVATE, new cbEventFunctor<BrowseTracker, CodeBlocksEvent>(this, &BrowseTracker::OnProjectActivatedEvent));

    // hook to project loading procedure
    // This hook only occurs if the project has an "extension" xml entry
    ProjectLoaderHooks::HookFunctorBase* myProjhook = new ProjectLoaderHooks::HookFunctor<BrowseTracker>(this, &BrowseTracker::OnProjectLoadingHook);
    m_ProjectHookId = ProjectLoaderHooks::RegisterHook(myProjhook);




EVT_PROJECT_ACTIVATE?
EVT_PROJECT_OPEN?


Any Comments?

Thanks!

« Last Edit: December 15, 2012, 06:19:15 am by ollydbg »
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Some thoughts on doing breakpoints persistant
« Reply #1 on: June 16, 2009, 12:11:45 pm »
I think both "breakpoints" list and "watch variables list" can be automatically saved to hard disk, and loaded when a project opened.
Notice that the watches can already be saved/loaded. You can have a look at how this is done...

Notice that this info should *not* be in a project file. This is developer-specific and not project specific. It mus be an external (addon) file or alike.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Some thoughts on doing breakpoints persistant
« Reply #2 on: June 16, 2009, 12:43:43 pm »
Do we have such common file? Or everybody should save to his/her own file?
Visual studio for example uses project_name.user file for such thing?
We can do something similar and provide a common interface for it.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Some thoughts on doing breakpoints persistant
« Reply #3 on: June 16, 2009, 12:56:21 pm »
We can do something similar and provide a common interface for it.
Probably a "layout" file would do. Similar like it's done with the project layout.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline Jenna

  • Administrator
  • Lives here!
  • *****
  • Posts: 7255
Re: Some thoughts on doing breakpoints persistant
« Reply #4 on: June 16, 2009, 01:01:52 pm »
We can do something similar and provide a common interface for it.
Probably a "layout" file would do. Similar like it's done with the project layout.

This is developer-specific and not project specific. It mus be an external (addon) file or alike.
That's the same for the layout-file we have at the moment and should probably be changed in a similar way we might do for watches/bp's.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Some thoughts on doing breakpoints persistant
« Reply #5 on: June 16, 2009, 02:14:52 pm »
That's the same for the layout-file we have at the moment and should probably be changed in a similar way we might do for watches/bp's.
Why? I don't put the layout files under version control because that's *my* setup. So if the BP's are also in some kind of layout file it'd be OK... or not?!
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline killerbot

  • Administrator
  • Lives here!
  • *****
  • Posts: 5491
Re: Some thoughts on doing breakpoints persistant
« Reply #6 on: June 16, 2009, 02:22:08 pm »
yes, breakpoints should not be in cbp, put in a file which should not be version controlled.

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5913
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Some thoughts on doing breakpoints persistant
« Reply #7 on: June 16, 2009, 03:32:47 pm »
In the browsetracker plugin, all the "browse_Marks" will be recorded in a your_project_name.bmarks file.

It is a XML file format. For example:

Code
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<BrowseTracker_layout_file>
<ActiveTarget name="Debug" />
<File name="LearnWX1App.cpp" open="1" top="0" tabpos="4">
<Cursor position="646" topLine="0" />
<BrowseMarks positions="472,646" />
<Book_Marks positions="" />
</File>
<File name="LearnWX1Main.cpp" open="1" top="0" tabpos="1">
<Cursor position="3467" topLine="67" />
<BrowseMarks positions="1728,2413,3467" />
<Book_Marks positions="" />
</File>
<File name="LearnWX1Main.h" open="1" top="0" tabpos="2">
<Cursor position="1476" topLine="24" />
</File>
<File name="resource.rc" open="0" top="0" tabpos="0">
<Cursor position="48" topLine="0" />
</File>
<File name="wx_pch.h" open="1" top="0" tabpos="3">
<Cursor position="396" topLine="0" />
</File>
</BrowseTracker_layout_file>

Every files will be recorded, including the "tab position", the Cursor position, the "BrowseMarks positions".

Seems we can just add another entry like below
Code
<File name="LearnWX1App.cpp" open="1" top="0" tabpos="4">
<Cursor position="646" topLine="0" />
<BrowseMarks positions="472,646" />
<Book_Marks positions="" />
                <Break_Points positions= "XXXXXX, XXXXXX, XXXXXX"
</File>

Edit: This will be mess up  :(, debuggerGDB plugin should have its own layout file like

your_project_name.bps


 :D
« Last Edit: June 16, 2009, 03:34:33 pm by ollydbg »
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Some thoughts on doing breakpoints persistant
« Reply #8 on: June 16, 2009, 03:55:10 pm »
Having 100 files in the project's directory is bad and ugly.

There should be only one file looking like:

Code
<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<cb_project_setting>
       <layout> ala bala </layout>
       <debugger_plugin> ala bala </debugger_plugin>
       <browse_tracker_plugin> </browse_tracker_plugin>
       .
       .
</cb_project_setting>

And there should be an easy way to get your data:
Code
CProjData *data = some_manager->GetProjectSettings()->GetData("layout");

do something with the data....

 some_manager->GetProjectSettings()->SetData("layout", data);

p.s. by the way, I don't know what is the API for dealing with xml inside C::B :)
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5913
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Some thoughts on doing breakpoints persistant
« Reply #9 on: June 16, 2009, 04:10:44 pm »
It use tinyXML related functions.

See: Source/Base/tinyXML/*.cpp

your_project_name.cbp
your_project_name.layout
your_project_name.bmarks

all the above files have the same XML format. :D
« Last Edit: June 16, 2009, 04:13:08 pm by ollydbg »
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Some thoughts on doing breakpoints persistant
« Reply #10 on: June 16, 2009, 04:55:06 pm »
There should be only one file looking like:
Sure not! I don't want to share my breakpoints with other developers on the same project.

So settings like BP's cannot be in the project file. Because that's what you share with other developers. In addition it would be modified every time you change a BP. However - important settings about the setup of the debugger itself (e.g. parameters for a remote connection) belong into the project file so that's why we have that "debugger" section there.

So it would not be 100 files. It's a 1:1 relation to your project file. but it's local ("for your eyes") only because that's how the use case is in the end.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Some thoughts on doing breakpoints persistant
« Reply #11 on: June 16, 2009, 05:06:40 pm »
Yes, I'm not saying to put the user settings in the project file.
I'm saying that I don't want to have 10-20 files in my project dir:
myproject.layout
myproject.bps
myproject.books
myproject.svnplg
myproject.whatnot

but just one:

myproject.user.settings (for example) that is not in svn as the other.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]

Offline ollydbg

  • Developer
  • Lives here!
  • *****
  • Posts: 5913
  • OpenCV and Robotics
    • Chinese OpenCV forum moderator
Re: Some thoughts on doing breakpoints persistant
« Reply #12 on: June 16, 2009, 05:40:30 pm »
I suggest the first step is to use separate setting files.

then after that, we can combine them together, I'm concerning mutiply-accessing to single file from different plugins will cause conflicts.
If some piece of memory should be reused, turn them to variables (or const variables).
If some piece of operations should be reused, turn them to functions.
If they happened together, then turn them to classes.

Offline MortenMacFly

  • Administrator
  • Lives here!
  • *****
  • Posts: 9694
Re: Some thoughts on doing breakpoints persistant
« Reply #13 on: June 16, 2009, 06:01:01 pm »
myproject.user.settings (for example) that is not in svn as the other.
Agreed.
I'm concerning mutiply-accessing to single file from different plugins will cause conflicts.
Indeed. So the only solution I see is that the core provides methods to the plugin to write settings into a file handled by the core. This way all plugins have the possibility to store their (volatile) information in a file other than the project file. Still plugin may need own config files. So we cannot ensure it'll stay a single file.
Compiler logging: Settings->Compiler & Debugger->tab "Other"->Compiler logging="Full command line"
C::B Manual: https://www.codeblocks.org/docs/main_codeblocks_en.html
C::B FAQ: https://wiki.codeblocks.org/index.php?title=FAQ

Offline oBFusCATed

  • Developer
  • Lives here!
  • *****
  • Posts: 13413
    • Travis build status
Re: Some thoughts on doing breakpoints persistant
« Reply #14 on: June 16, 2009, 06:06:08 pm »
Indeed. So the only solution I see is that the core provides methods to the plugin to write settings into a file handled by the core. This way all plugins have the possibility to store their (volatile) information in a file other than the project file. Still plugin may need own config files. So we cannot ensure it'll stay a single file.

We talk about data per project.
If a plugin needs some global configuration, the core can(must) still provide an interface for storing settings.
(most of the time I ignore long posts)
[strangers don't send me private messages, I'll ignore them; post a topic in the forum, but first read the rules!]