configure file to debug codecompletion plugin

[ollydbg]

Sometimes, I fill it takes several times to let the GDB load all the plugins, so I have complain there:
Is there a C::B command line option support loading a specific plugin

And the developers of C::B give me some ideas. Finally I totally agree with mariocup's way. So, here is the configure file you can change.

Code

			<plugins>
		<TRY_TO_ACTIVATE>
			<str>
				<![CDATA[]]>
			</str>
		</TRY_TO_ACTIVATE>
		<INSTALL_GLOBALLY bool="1" />
		<INSTALL_CONFIRMATION bool="1" />
		<ASTYLEPLUGIN bool="0" />
		<AUTOSAVE bool="0" />
		<AUTOVERSIONING bool="0" />
		<BROWSETRACKER bool="0" />
		<BYOGAMES bool="0" />
		<CB_KODERS bool="0" />
		<CCCC bool="0" />
		<CLASSWIZARD bool="0" />
		<CODECOMPLETION bool="1" />
		<CODESNIPPETS bool="0" />
		<CODESTAT bool="0" />
		<COMPILER bool="1" />
		<COPYSTRINGS bool="0" />
		<CPPCHECK bool="0" />
		<DEBUGGER bool="0" />
		<FILESEXTENSIONHANDLER bool="0" />
		<DEVPAKUPDATER bool="0" />
		<CBDRAGSCROLL bool="0" />
		<ENVVARS bool="0" />
		<EXPORTER bool="0" />
		<HEADERFIXUP bool="0" />
		<HEXEDITOR bool="0" />
		<INCREMENTALSEARCH bool="0" />
		<CBKEYBINDER bool="0" />
		<LIB_FINDER bool="0" />
		<MOUSESAP bool="0" />
		<OPENFILESLIST bool="0" />
		<PROFILER bool="0" />
		<PROJECTSIMPORTER bool="0" />
		<REGEXTESTBED bool="0" />
		<SCRIPTEDWIZARD bool="0" />
		<SYMTAB bool="0" />
		<THREADSEARCH bool="0" />
		<TODOLIST bool="0" />
		<WXSMITH bool="0" />
		<WXSMITHMIME bool="0" />
		<WXSMITHAUI bool="0" />
		<WXSMITHCONTRIBITEMS bool="0" />
		<WINDOWSXPLOOKNFEEL bool="0" />
		<CCPP_TEST_PLUGIN bool="0" />
		<CSCOPE bool="0" />
		<DOXYBLOCKS bool="0" />
		<EDITORTWEAKS bool="0" />
		<SPELLCHECKER bool="0" />
		<HELPPLUGIN bool="0" />
	</plugins>

set zero will let C::B do not load the plugin. For debugging CC, you need only enable several plugins.


Then you need to change the start argument of src target:

--debug-log --no-check-associations -ns -nd -p=debugCC


Then, you need to modify the "debugCC.conf" file.


BTW: debugCC.conf file can be somewhere in:

C:\Documents and Settings\YOUNAME\Application Data\codeblocks

For me, I run the portable C::B from:
E:\code\cb\cb_app (which as a "CbLauncher.exe" in this folder ).
Then the debugCC.conf file is located in:
E:\code\cb\cb_app\AppData\codeblocks


Happy debugging !!!!!

[ollydbg]

By the way, the related source code when loading a plug-in is in:

sdk\pluginmanager.cpp

Code

void PluginManager::LoadAllPlugins()
{
    // check if a plugin crashed the app last time
    wxString probPlugin = Manager::Get()->GetConfigManager(_T("plugins"))->Read(_T("/try_to_activate"), wxEmptyString);
    if (!probPlugin.IsEmpty())
    {
        wxString msg;
        msg.Printf(_("Plugin \"%s\" failed to load last time Code::Blocks was executed.\n"
                    "Do you want to disable this plugin from loading?"), probPlugin.c_str());
        if (cbMessageBox(msg, _("Warning"), wxICON_WARNING | wxYES_NO) == wxID_NO)
            probPlugin = _T("");
    }

    PluginElement* elem = 0;
    for (unsigned int i = 0; i < m_Plugins.GetCount(); ++i)
    {
        elem = m_Plugins[i];
        cbPlugin* plug = elem->plugin;
        if (!plug || plug->IsAttached())
            continue;

        // do not load it if the user has explicitly asked not to...
        wxString baseKey;
        baseKey << _T("/") << elem->info.name;
        bool loadIt = Manager::Get()->GetConfigManager(_T("plugins"))->ReadBool(baseKey, true);

        // if we have a problematic plugin, check if this is it
        if (loadIt && !probPlugin.IsEmpty())
        {
            loadIt = elem->info.title != probPlugin;
            // if this is the problematic plugin, don't load it
            if (!loadIt)
                Manager::Get()->GetConfigManager(_T("plugins"))->Write(baseKey, false);
        }

        if (loadIt)
        {
            Manager::Get()->GetConfigManager(_T("plugins"))->Write(_T("/try_to_activate"), elem->info.title);
            Manager::Get()->GetLogManager()->Log(elem->info.name);
            try
            {
                AttachPlugin(plug);
                Manager::Get()->GetConfigManager(_T("plugins"))->Write(_T("/try_to_activate"), wxEmptyString, false);
            }
            catch (cbException& exception)
            {
                Manager::Get()->GetLogManager()->Log(_T("[failed]"));
                exception.ShowErrorMessage(false);

                wxString msg;
                msg.Printf(_("Plugin \"%s\" failed to load...\n"
                            "Do you want to disable this plugin from loading next time?"), elem->info.title.c_str());
                if (cbMessageBox(msg, _("Warning"), wxICON_WARNING | wxYES_NO) == wxID_YES)
                    Manager::Get()->GetConfigManager(_T("plugins"))->Write(baseKey, false);
            }
        }
    }
    Manager::Get()->GetConfigManager(_T("plugins"))->Write(_T("/try_to_activate"), wxEmptyString, false);
}

So, you can see how a plugin is loaded depend on the configure files.

[ollydbg]

Ok, I found that even I have "disable some plugins" by setting

Code

<PLUGIN_NAME bool="0" />

But all the dlls will still be loaded. I have find that in the source file:

Code

int PluginManager::ScanForPlugins(const wxString& path)
{
    static const wxString PluginsMask = platform::windows ? _T("*.dll") : _T("*.so");
    int count = 0;
    if(!wxDirExists(path))
        return count;
    wxDir dir(path);

    if (!dir.IsOpened())
        return count;

    bool batch = true; //Manager::IsBatchBuild(); //**********************I have force it to "true"
    wxArrayString bbplugins;
    if (batch)
    {
        ConfigManager *bbcfg = Manager::Get()->GetConfigManager(_T("plugins"));
        bbplugins = bbcfg->ReadArrayString(_T("/batch_build_plugins"));
        if (!bbplugins.GetCount())
        {
            // defaults
            if(platform::windows)
                bbplugins.Add(_T("compiler.dll"));
            else
                bbplugins.Add(_T("libcompiler.so"));
        }
    }

    wxString filename;
    wxString failed;
    bool ok = dir.GetFirst(&filename, PluginsMask, wxDIR_FILES);
    while (ok)
    {
        if (batch)
        {
            // for batch builds, we will load only those plugins that the
            // user has set (default only compiler.dll)
            bool matched = false;
            for (size_t i = 0; i < bbplugins.GetCount(); ++i)
            {
                if (bbplugins[i] == filename)
                {
                    matched = true;
                    break;
                }
            }
            if (!matched)
            {
                ok = dir.GetNext(&filename);
                continue;
            }
        }

        // load manifest
        m_pCurrentlyLoadingManifestDoc = 0;
        if (ReadManifestFile(filename))
        {
            if (LoadPlugin(path + _T('/') + filename))
                ++count;
            else
                failed << _T('\n') << filename;
        }
        if (m_pCurrentlyLoadingManifestDoc)
        {
            delete m_pCurrentlyLoadingManifestDoc;
            m_pCurrentlyLoadingManifestDoc = 0;
        }
        ok = dir.GetNext(&filename);
    }
    Manager::Get()->GetLogManager()->Log(F(_("Loaded %d plugins"), count));
    if (!failed.IsEmpty())
    {
        InfoWindow::Display(_("Warning"),
                            _("One or more plugins were not loaded.\n"
                            "This usually happens when a plugin is built for\n"
                            "a different version of the Code::Blocks SDK.\n"
                            "Check the application log for more info.\n\n"
                            "List of failed plugins:\n") + failed,
                            15000, 3000);
    }
    return count;
}

I have force the "batch" value to "true", then in the debugCC.conf file, I add some options like:

Code

	<plugins>
		<TRY_TO_ACTIVATE>
			<str>
				<![CDATA[]]>
			</str>
		</TRY_TO_ACTIVATE>
		<BATCH_BUILD_PLUGINS>
			<astr>
				<s>
					<![CDATA[codecompletion.dll]]>
				</s>
				<s>
					<![CDATA[compiler.dll]]>
				</s>
			</astr>
		</BATCH_BUILD_PLUGINS>
.....

Now, only these two plugins will be loaded. which make gdb loading much faster for debugging CC.

Note: This is method is only used to fast debug CC on windows. If you like to debug some single plugins, you can try the same way.

by using this way, GDB.exe is only eat about 95M(only load codecompletion and compiler plugin dll) memory compared with 250M(all the plugin dll were loaded). Cool!!

[ollydbg]

In the previous post in this thread, I have find some way to disable gdb.exe to load many debug symbol files. But even I do that, I found it is still need 90 seconds to start the new c::b in gdb.

So, I guess the problem is: I have a big file "codeblock.dll" in my E:\code\cb\cc_branch\src\devel, it is 40+M. So, gdb sucks on loading this file.  :wink:  Sometimes, I only need to "debug the Codecompletion plugin".

Here is another way I think we can do :

1, copy the  E:\code\cb\cc_branch\src\devel\share\CodeBlocks\plugins\codecompletion.dll to
                  E:\code\cb\cc_branch\src\output\share\CodeBlocks\plugins
   so that the debug information can be reserved.

2, select the "building target" to "code-completion"

3, and setting the host program to codeblocks.exe in output folder, see the screen shot below:



4, press the start debugging button, now, c::b is loading much faster(about 10 seconds), the side effect is we have only debug information in "codecompletion.dll". 

[oBFusCATed]

On linux you can split the debugging info from the executable and the shared libraries.
I don't know if this is possible on windows, but you could try it.
Also your version of gdb is extremely slow, compared to the linux one, and 2x-5x time slower that the previous gdb.exe I've used on windows.

[ollydbg]

On linux you can split the debugging info from the executable and the shared libraries.
I don't know if this is possible on windows, but you could try it.
Also your version of gdb is extremely slow, compared to the linux one, and 2x-5x time slower that the previous gdb.exe I've used on windows.

thanks for the reply.

2x-5x time slower that the previous gdb.exe I've used on windows.

can you tell me which version of gdb did you use before?

[oBFusCATed]

No, I can't, I use windows on rare occasions, but probably it was the one in the gdb 7.0 thread here in the forum.

[ollydbg]

No, I can't, I use windows on rare occasions, but probably it was the one in the gdb 7.0 thread here in the forum.

For me, I have used gdb.exe 6.8.3, 7.0, 7.0.1 .7.0.50 7.1, every one has very slow speed of loading the big "codeblocks.dll". I don't have experience that my published gdb.exe has 2X-5X slower than the official gdb. 

BTW: does any one have the same issue? thanks.

[Pecan]

I find when debugging CB devel with CB output that loading is extreemly slow when a breakpoint is set.

So, instead of a breakpoint, I place an "asm("int3")" statement at the point I want to begin debugging. CB then loads within 4-10 seconds.
When the int 3 is hit, I then set more breakpoints.

[ollydbg]

So, instead of a breakpoint, I place an "asm("int3")" statement at the point I want to begin debugging. CB then loads within 4-10 seconds.
When the int 3 is hit, I then set more breakpoints.

Thanks for your reply.
I will test it soon.

I find when debugging CB devel with CB output that loading is extremely slow when a breakpoint is set.

This is too wired...

[ollydbg]

So, instead of a breakpoint, I place an "asm("int3")" statement at the point I want to begin debugging. CB then loads within 4-10 seconds.
When the int 3 is hit, I then set more breakpoints.

Thanks for your reply.
I will test it soon.

I find when debugging CB devel with CB output that loading is extremely slow when a breakpoint is set.

This is too wired...

Hi, all, I can fully confirm that when a breakpoint is set before loading, then it will take 90 seconds to debugging CB devel.

But strange that when I set a breakpoint after the loading, the loading time is quite fast(about 10 seconds), then the breakpoint works fine as the first situation.  I will report this to the gdb maillist, it is too wired.

As a workaround, can C::B setting breakpoints immediately after loading finishes.

[oBFusCATed]

As a workaround, can C::B setting breakpoints immediately after loading finishes.

Probably, it can't, but you could try to first run C::B and then attach to it. (There is a chance that the attach will fail, at least in the debugger branch attaching to C::B doesn't work (should fix it, someday))

This behavior looks like a bug in gdb... on linux the starting time of C::B with and without gdb is almost the same (+5 seconds for gdb to load C::B)...

[ollydbg]

This behavior looks like a bug in gdb... on linux the starting time of C::B with and without gdb is almost the same (+5 seconds for gdb to load C::B)...

Hi, oBF.
Can you try this on Linux
1, setting some breakpoint on some files (before debugging)
2, start debugging C::B(The debugee  "devel" folders) under C::B.
3, see how long the debugee start up.

If without the step 1, the debugee start up really quickly in Windows(5-10 seconds ,with all plugins).

I have read a bit about the gdb source. When gdb load a new symbol file, it will check all the breakpoint to see if the pending breakpoint can be set correctly.

For example, when starting C::B, we have about 40 symbol files to load( include all the plugin shared libraries), every time a shared library and its symbol file are loaded, it will call a function named " breakpoint_re_set ", then all breakpoint will be "re checked", this may cause the time delay.

[oBFusCATed]

I've debugged c::b with all plugins (not sure about contrib ones) and I've not seen any difference, so if there is such it is 5-10 sec maximum.

[ollydbg]

Thanks.
I think it is a gdb bug on windows. I have reported to both gdb and mingw maillist. Hopefully some gdb guru can fix it.