Author Topic: configure file to debug codecompletion plugin (Read 28678 times)

ollydbg · « **on:** July 20, 2010, 03:54:23 pm »

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 · « **Reply #1 on:** July 20, 2010, 03:57:10 pm »

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 · « **Reply #2 on:** July 21, 2010, 01:50:18 am »

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 · « **Reply #3 on:** July 21, 2010, 02:35:04 am »

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 · « **Reply #4 on:** July 21, 2010, 09:28:54 am »

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 · « **Reply #5 on:** July 21, 2010, 10:33:42 am »

Quote from: oBFusCATed on July 21, 2010, 09:28:54 am

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.

Quote

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 · « **Reply #6 on:** July 21, 2010, 11:02:14 am »

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 · « **Reply #7 on:** July 21, 2010, 03:02:06 pm »

Quote from: oBFusCATed on July 21, 2010, 11:02:14 am

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 · « **Reply #8 on:** July 21, 2010, 03:29:26 pm »

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 · « **Reply #9 on:** July 21, 2010, 03:33:58 pm »

Quote from: Pecan on July 21, 2010, 03:29:26 pm

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.

Quote

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

This is too wired...

ollydbg · « **Reply #10 on:** July 21, 2010, 03:41:26 pm »

Quote from: ollydbg on July 21, 2010, 03:33:58 pm

Quote from: Pecan on July 21, 2010, 03:29:26 pm
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.

Quote
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 · « **Reply #11 on:** July 21, 2010, 03:47:37 pm »

Quote from: ollydbg on July 21, 2010, 03:41:26 pm

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 · « **Reply #12 on:** July 22, 2010, 07:34:04 am »

Quote from: oBFusCATed on July 21, 2010, 03:47:37 pm

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 · « **Reply #13 on:** July 22, 2010, 09:12:52 am »

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 · « **Reply #14 on:** July 22, 2010, 03:50:59 pm »

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.

ollydbg · « **Reply #15 on:** July 22, 2010, 04:39:52 pm »

By the way, there are some gdb command to show how long the gdb command will response. ( this can measure the wxString showing delay problem several months ago I posted

)

Maintenance Commands - Debugging with GDB

Here is the debugger log:

Quote

>>>>>>cb_gdb:
> maint time
"maintenance time" takes a numeric argument.
>>>>>>cb_gdb:
> maint time 1
Command execution time: 0.000000
>>>>>>cb_gdb:
> next
E:\code\cb\cc_branch\src\src\main.cpp:479:24053:beg:0x416c17
Command execution time: 0.000000
>>>>>>cb_gdb:
> next
[New Thread 2780.0xa04]
[New Thread 2780.0xbb4]
E:\code\cb\cc_branch\src\src\main.cpp:482:24131:beg:0x416c4b
Command execution time: 0.140000
>>>>>>cb_gdb:
> break "E:/code/cb/cc_branch/src/plugins/codecompletion/parser/parserthread.cpp:472"
No source file named E:/code/cb/cc_branch/src/plugins/codecompletion/parser/parserthread.cpp.
Breakpoint 2 ("E:/code/cb/cc_branch/src/plugins/codecompletion/parser/parserthread.cpp:472) pending.
Command execution time: 4.453000
>>>>>>cb_gdb:
> break "E:/code/cb/cc_branch/src/plugins/codecompletion/parser/parserthread.cpp:474"
No source file named E:/code/cb/cc_branch/src/plugins/codecompletion/parser/parserthread.cpp.
Breakpoint 3 ("E:/code/cb/cc_branch/src/plugins/codecompletion/parser/parserthread.cpp:474) pending.
Command execution time: 3.875000
>>>>>>cb_gdb:

It will take several seconds to let gdb to set a pending breakpoint... too slow...

Edit: which means after a new dll is loaded, gdb need to check if a pending breakpoint can be convert to a normal breakpoint, but it seems one check need about 4 seconds, So, if we have 30 dll to loade, the checking time should be 4*30= 120 seconds..... Oh my God!!

ollydbg · « **Reply #16 on:** July 24, 2010, 01:00:41 pm »

Quote from: ollydbg on July 21, 2010, 02:35:04 am

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.

We even don't need to manually copy the dll file, we can just set the path of the generated dll file.

You need to change the "devel" to "output".

Than, every thing works fine!

ollydbg · « **Reply #17 on:** November 06, 2011, 10:21:29 am »

Quote from: Pecan on July 21, 2010, 03:29:26 pm

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.

Sorry for bump the old thread.
Hi, All and Pecan.
There are good news on this issue, the gdb guys supply a patch to fix this issue.
See my comments here:
http://sourceware.org/ml/gdb-patches/2011-11/msg00141.html

I have test this patch, and found that CB/gdb start up extremely fast with pending breakpoints under WinXP. This will make debugging plugins much faster and more happy.

oBFusCATed · « **Reply #18 on:** November 06, 2011, 10:27:50 am »

Hm, this sounds great, I hope it is not windows only.
My app at work has even more shared libraries than C::B and when I set breakpoint somewhere it takes more than a minute to start it, which is very annoying

News:

Author Topic: configure file to debug codecompletion plugin (Read 28678 times)