Code::Blocks Forums

Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: oBFusCATed on July 26, 2009, 01:27:44 pm

Title: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on July 26, 2009, 01:27:44 pm
Hello,

I've played a bit with the GDB plugin trying to increase its speed, but I'm sure that is not possible much.
So I decided to make a new plugin using the GDB/mi interface.
I've done some testing made the thing execute commands and handle the output, but there is one major problem of C::B in that regard:
I've to reimplement all the GUI - watch, threads, call stack, register windows and menu.
I've reimplemented the menu, so I can play with it and now in my CB there are two menus one is Debug and the other Debug/MI.
And that is with only two debuggers, the mess will be massive if someone implements Lua (I would do it if we get the common interface), Python, etc debuggers.

My idea is to split the debugger plugin in two parts: a plugin that communicates with the actual debugger and a plugin/sdk that implements the GUI.
I would do the whole thing, I just need guidance, little help and a green light, so I know that this change is desired.

Best regards,
Teodor
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on July 26, 2009, 01:36:37 pm
Great!
But what does "GDB/mi interface" means?

By the way: I found that the current GDB may add some python add-on, I'm not sure you can use them.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on July 26, 2009, 04:19:22 pm
ollydbg: see here http://sources.redhat.com/gdb/current/onlinedocs/gdb_26.html#SEC270 (http://sources.redhat.com/gdb/current/onlinedocs/gdb_26.html#SEC270) about gdb/mi ...
I don't care about python at the moment or ever will, what I want is to make extending debugging in CB easier.
Python/Lua were just examples what could be done in the future.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on July 26, 2009, 08:45:07 pm
My idea is to split the debugger plugin in two parts: a plugin that communicates with the actual debugger and a plugin/sdk that implements the GUI.
I understand why you want to do this, but isn't it possible (with the current code) to derive those UI parts from existing code and override the "incompatible" parts? If not I think it should be done careful, meaning taking other debuggers into account, too. That is if we do a general UI for GDB and GDB/MI the question is does it work with CDB and others, too? (Not saying it's not doable.)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on July 26, 2009, 09:30:08 pm
Morten how could I (in the GDB/mi plugin) derive from classes in GDB plugin? Or I have understood you incorrectly?

I don't think CDB is a concern because the current implementation works for both (only the drivers are different).
The hardest thing to abstract in the debugger part of CB is the watch window, the others would be straight forward.

For example the call stack window usage could look like this:
Code

void MyDBG::OnUpdateCallStack()
{
    cbCallStackWindow *window = Manager::Get()->GetDebuggerUI(CB_DBG_UI_CALL_STACK);

    if(!window || !window->IsVisible())
        return;

    window->StartUpdating();

    foreach(frame in m_call_stack_frames)
    {
        window->AddFrame(cbCallStackFrame(frame.path, frame.addr, frame.symbol));
    }
    window->FinishUpdating();
}
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on July 28, 2009, 08:34:50 am
Morten how could I (in the GDB/mi plugin) derive from classes in GDB plugin?
Erm... just like
Code
class Gdb
{
    public:
        void GdbFunction(){ // gdb code }
};

class NewGdb : public Gdb
{
    public:
        void GdbFunction(){ // new_gdb code }
        void NewGdbFunction(){}
};

void new_gdb_plugin()
{
    NewGdb new_gdb;
}
etc... But probably I have misunderstood?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on July 28, 2009, 10:52:07 am
Erm... just like
Code
class Gdb
{
    public:
        void GdbFunction(){ // gdb code }
};

class NewGdb : public Gdb
{
    public:
        void GdbFunction(){ // new_gdb code }
        void NewGdbFunction(){}
};

void new_gdb_plugin()
{
    NewGdb new_gdb;
}
etc... But probably I have misunderstood?
First you have missed the virtual up there:)
The question was a bit rhetorical, though. I can derive from a class that is not exported (no public include, no __declspec(export/import)).
To be able to derive from such class, some changes should be made in the current debugger plugin. Also my new plugin would become dependent on the old one, but it should work with the old plugin, there should not be related in any way.

Decoupling the gui from the debugger plugin will make writing of both easier. Also the plugins would be easier to read, understand and extend.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on July 28, 2009, 12:11:01 pm
First you have missed the virtual up there:)
Nar... but you got the idea.

Decoupling the gui from the debugger plugin will make writing of both easier. Also the plugins would be easier to read, understand and extend.
So - I have no doubts about that but again my question is: If we "polish" the current interfaces / classes so we can derive from them where needed may b less work. But it's really just a question - so it's probably not.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on July 28, 2009, 01:14:22 pm
I suppose the simpler windows (call stack, threads, registers) could be modified, and not rewritten from scratch.
But the most complex and time consuming window, the watch window, could not.
In my opinion it should be rewritten using the PropGrid class/widget (or something similar). At the moment it is quite annoying and not user friendly.

So do I have a green light to start working on such a feature/refactoring? And would my work be accepted in C::B?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on July 28, 2009, 03:20:27 pm
So do I have a green light to start working on such a feature/refactoring?
Sure - who can stop you anyways?! ;-)

And would my work be accepted in C::B?
If it's working and well written I am happy to keep track and apply if ready. Please just try to use the same style as in the debugger plugin.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: mariocup on July 28, 2009, 03:29:11 pm
Hi oBFusCATed,

some time ago I collect some requirements that I see for a debugger, especially if you want to use it for embedded application (see Section Embedded at http://wiki.codeblocks.org/index.php?title=User_talk:Mariocup).
The most important features in my eyes are:
- Extension Points for options
- Mixed Mode
- Multiple Watch Windows

If you are refactoring it, perhaps there will be some new concepts to integrate some of the features :D.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on July 29, 2009, 12:04:29 am
Sure - who can stop you anyways?! ;-)
That is true, but I don't want to maintain extremely modified copy of CB, so if the changes would be accepted in the main source, I'll do better work.

If it's working and well written I am happy to keep track and apply if ready. Please just try to use the same style as in the debugger plugin.
Coding style?

Another thing:
I need to keep the thing in a VCS, shuffling patches around would be nasty.
There are some options:
1. I could import the thing in a git repo and publish it, but I'm not sure how well does git works on windows. And I've never used git before.
2. You could make me new branch in the official repo, and give me write access to that branch, so you can follow the progress and stop me from doing stupid things early in the process.
3. Any other option you could think of, and I've missed.

p.s. I don't insist on option 2
p.s.s. mariocup: It is too early to think about such features, though some of the sound logical and not that hard to implement, so time will tell what will happen :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on July 29, 2009, 08:05:57 am
Coding style?
Yes - we have some instructions accordingly in the WiKi.

I need to keep the thing in a VCS, shuffling patches around would be nasty.
3. Any other option you could think of, and I've missed.
Granting access on out repo can only one: The Admin Yiannis.
But I suggest you create yourself an account on BerliOS (so that we share the same platform) and have your own repo there... just as a lot other plugins do it, too. It's very simple to setup.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on July 29, 2009, 04:38:58 pm
I'm not sure that I like berlios, so if it will be external repo I'll go with GIT.
Because it has svn integration, so syncing my repo with trunk will be easier.
And it's time to learn it :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on August 01, 2009, 10:36:13 am
I've started working on it ... and I have a little problem:
Where do I put a new header that should not be visible to the users in the sdk, only by the implementation?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on August 01, 2009, 05:18:54 pm
Where do I put a new header that should not be visible to the users in the sdk, only by the implementation?
Huh? What exactly do you mean? Notice that if the SDK needs this header file it had to be available.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on August 02, 2009, 10:35:09 am
I have:
a.h,b.h,a.cpp,b.cpp

in a.cpp I include b.h. b.h is included in no other header, so it should not be visible to the users of the sdk.

Where do I put b.h? At the moment I've put it in src\include.

Another thing:

I want to add the method:

void cbDebuggerPlugin::GetBreakpoints(some_container_type &container);

What should be the some_container_type?
WX_DEFINE_ARRAY(cbBreakPoint*, BreakpointsList); ?
std::vector<cbBreakPoint> ?
or class cbBreakPointList, that I have to define, manually?

The elements in the container should be owned by the container.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on August 03, 2009, 07:28:11 am
in a.cpp I include b.h. b.h is included in no other header, so it should not be visible to the users of the sdk.
Just leave it where it is. The SDK docu will take care of not including this file in the documentation. Alternatively (if it's a small helper class) you can also embed it on top of the actual class (so in a.h) and comment it accordingly. There are several SDK classes that do similar (with the embedded classes *not* to be used directly).

WX_DEFINE_ARRAY(cbBreakPoint*, BreakpointsList); ?
std::vector<cbBreakPoint> ?
I'd personally prefer the first, but if that would be the only "wx code" and you'd strive for portability sure std::vector is the thing to do.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on August 13, 2009, 01:45:32 am
I've some progress....  :lol: 8)

0. I've added a DebuggerManager, to hold all debugger related stuff
1. I've extracted the Debug menu (should move the resource file thought). The code is moved in the DebuggerMenu class.
1.1. Some of the menu items work (start, stop, step, next, continue)
1.2. I've added submenu Debug->Active Debugger. I've added API calls to register/unregister debuggers. The menu items are radio items, and switching the active debugger works.
2. I've extracted the breakpoints dialog and edit breakpoints
3. I've move the code from DebuggerGDB::SyncEditor to DebuggerManager::SyncEditor

Here is the patch that shows the changes: http://smrt.is-a-geek.org/codeblocks/dbg_refactor/dbg_refactor0001.patch
Parallel to the changes I make to CB, I modify my gdb_mi debugger plugin, so I can test if the changes are working.
The plugin can be found here: svn://smrt.is-a-geek.org/cb_gdb_mi .
The things that work: stepping and setting breakpoints at the beginning (before you have started the debugger).

Next on my TODO:
1. extracting the dbg toolbar
2. rewriting the watches window from scratch,  using PropGrid control - if you know about a control that is more suitable for it, please tell me (I'm a beginner in wx programming)

Any feedback is welcome.  :lol:
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: dmoore on August 13, 2009, 01:56:17 am
when you get this sufficiently ready, I'll try to make some time to offer myself as guinea pig and write a python debugger.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on August 13, 2009, 06:27:28 am
if you know about a control that is more suitable for it, please tell me (I'm a beginner in wx programming)
Great work so far. I'll try to apply the patch and see.
Concerning propgrid: If you want to use it please use the recent version of the wx (or wxCode) repo. Not the one bundled with wxSmith as this is very outdated. We have to update two plugins otherwise... ;-)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: mariocup on August 13, 2009, 08:02:21 am
Hi oBFrusCATed,

that sounds promising and I will take a look as soon as I have some free time.

Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on August 13, 2009, 08:32:43 am
Firstly, Thanks for your hard work!!!
The patches is only for Linux-like system, because only "CodeBlocks-unix.cbp" was modified. But I only has Windows system at hand. So, I need time to tune.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on August 13, 2009, 09:30:23 am
You could edit the patch manually and replace Codeblocks-unix.cbp with Codeblocks.cbp, it might work.
Although the changes aren't too massive, 4 new files and some moved files.

If someone fixes the windows project, he/she can send me the patch...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on August 13, 2009, 12:44:27 pm
My first question is:

It seems there are files to be added to "sdk"(mainly header files), such as:

Code
@@ -508,6 +522,9 @@
  <Unit filename="include/editarraystringdlg.h">
  <Option target="sdk" />
  </Unit>
+ <Unit filename="include/editbreakpointdlg.h">
+ <Option target="sdk" />
+ </Unit>
  <Unit filename="include/editkeywordsdlg.h">
  <Option target="sdk" />
  </Unit>

and some files were added to "debugger"( mainly cpp files)

Code
@@ -1467,12 +1484,6 @@
  <Unit filename="plugins/debuggergdb/backtracedlg.h">
  <Option target="Debugger" />
  </Unit>
- <Unit filename="plugins/debuggergdb/breakpointsdlg.cpp">
- <Option target="Debugger" />
- </Unit>
- <Unit filename="plugins/debuggergdb/breakpointsdlg.h">
- <Option target="Debugger" />
- </Unit>
  <Unit filename="plugins/debuggergdb/cdb_commands.h">
  <Option target="Debugger" />
  </Unit>

So, my question is: Why not let them all stay in target "Debugger"?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on August 13, 2009, 12:45:57 pm
By the way, I can't directly apply your patch with TortoiseSVN.
So, I need to do it manually. :(

Edit
The only thing I would like to implement in sdk is that if we are debugging, we should only show the tooltip from debugger plugin. Currently, both codecompletion and debugger tooltip will be shown. Though, the former one will always be canceled by the later one.

See the related topic here:

http://forums.codeblocks.org/index.php/topic,10708.msg73482.html#msg73482
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on August 13, 2009, 02:04:17 pm
ollydbg: Please read the first post in the thread, there I've explained why I'm doing this.

p.s. sorry for you problems with applying it, I've made the patch with "git diff" and I haven't tried to apply it.
p.s.s. the debugger plugin has more serious problems (slowness, bad watch window, etc) than the one you mention, so they have higher priority  for me.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on August 15, 2009, 04:29:31 pm
I have a problem:
When I disable the DebuggerGDB plugin in "Plugin -> Manage plugins..." the "Debug" menu is removed.
Do someone knows where is the code that does the removal?
I couldn't find it and C::B crashes if I have two loaded debuggers and I try to disable both of them (tries to remove the menu twice).
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on August 15, 2009, 04:55:53 pm
Maybe, it is this function:

Code
bool PluginManager::DetachPlugin(cbPlugin* plugin)
{
    if (!plugin)
        return false;
    if (!plugin->IsAttached())
        return true;

    Manager::Get()->RemoveAllEventSinksFor(plugin);
    plugin->Release(Manager::IsAppShuttingDown());
    return true;
}

Then plugin->Release will do the whole job.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on August 15, 2009, 05:28:58 pm
I have a problem:
When I disable the DebuggerGDB plugin in "Plugin -> Manage plugins..." the "Debug" menu is removed.
Do someone knows where is the code that does the removal?
I couldn't find it and C::B crashes if I have two loaded debuggers and I try to disable both of them (tries to remove the menu twice).

I guess the error is another.
If a plugin is released the menubar gets recreated from scratch, no single menus get removed.
That means a menu can not be removed twice.
If you debug C::B from inside C::B you should be able to see the backtrace of the crash (if the call stack window is active) and put a breakpoint there to see the cause.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on August 15, 2009, 08:44:45 pm
Thanks Jens, that was it.

Do someone knows why the code for recreating the menu is something like this:

Code

SetMenuBar(0L);
mbar = new wxMenuBar;
FillTheMenuBar(mbar);
SetMenuBar(mbar);


I'm asking because I'm using Manager::Get()->GetAppWindow()->GetMenuBar() to create the debug menu, not the wxMenuBar supplied to the BuildMenu method.
And I get a crash because the menubar is NULL while menu recreation.

Edit:
Another issue I have is that I can't create the debugger toolbar from the sdk.
At the moment every plugin should implement the BuildToolbar method, which fill pre-supplied toolbar with some content. This means that every plugin has one toolbar that is unique.
I want to have only one debugger toolbar, that is shared by all debugger plugins.

What I've tried so far:
Code
void DebuggerToolbarHandler::LoadToolbar()
{
    if(m_toolbar)
        return;
    m_toolbar = Manager::Get()->CreateEmptyToolbar();
    wxString my_16x16 = Manager::isToolBar16x16(m_toolbar) ? _T("_16x16") : _T("");
    Manager::AddonToolBar(m_toolbar, wxString(_T("debugger_toolbar")) + my_16x16);
//    m_toolbar->Realize();
    m_toolbar->SetInitialSize();
//    m_toolbar->Show();

    wxAuiManager* layout = Manager::Get()->GetAppMainFrame()->GetLayoutManager();
    layout->AddPane(m_toolbar, wxAuiPaneInfo().
                              Name(_T("Debugger Toolbar")).Caption(_("Debugger Toolbar")).
                              ToolbarPane().Top().Row(1));
    Manager::Get()->GetAppMainFrame()->DoUpdateLayout();
}


/// Manager::Get()->GetAppMainFrame() returns:
class IMainFrame
{
public:
    virtual wxAuiManager* GetLayoutManager() = 0;
    virtual void DoUpdateLayout() = 0;
};
// that is implemented by the MainFrame class in main.cpp

The toolbar is created but it is not shown. I know that because I was calling layout->Update instead of DoUpdateLayout and some strange window have been shown while CB was starting, then disappears.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on August 31, 2009, 03:34:23 pm
Here is a screen shot of the new watches window in action:
http://smrt.is-a-geek.org/codeblocks/dbg_refactor/cb_new_watch.png (http://smrt.is-a-geek.org/codeblocks/dbg_refactor/cb_new_watch.png)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Ceniza on August 31, 2009, 04:36:36 pm
Here is a screen shot of the new watches window in action:
http://smrt.is-a-geek.org/codeblocks/dbg_refactor/cb_new_watch.png (http://smrt.is-a-geek.org/codeblocks/dbg_refactor/cb_new_watch.png)


I like it :D

Would it possible to add the tree branches to it?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on August 31, 2009, 05:32:30 pm
What are tree branches?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Ceniza on August 31, 2009, 05:33:57 pm
What are tree branches?

The dotted lines that show the connection between a node and all its children.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on August 31, 2009, 06:37:07 pm
I suppose no, because wxPropGrid might not support them at the moment (should look), but I can ask the it's creator, so he can add them (if not supported)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on August 31, 2009, 08:43:17 pm
I like it :D
/me, too! :P
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 01, 2009, 11:32:59 am
Little problem,
I want when a watch is selected and the user presses f2, to be able to edit it.
But the F2 is an accelerator key and it is not passed to the handler, so now I use the Insert key.
Is there a way to handle f2 in my window?

p.s. Glad you like it, I hope that I'll post a patch with finished watches utill the end of the week.

Edit:
Argh  ... .. . Another problem:
The editor is refocused when a context menu in the watches window or the "logs and others" is closed (menu item is clicked).
This behavior prevents the implementation of the context menu watchesdlg->context menu -> rename (which does inplace rename).

Does someone knows something about that?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 02, 2009, 07:24:22 pm
OK, here is the second patch that shows my progress on this... (see post #18 for the previous message regarding progress and patches)

Here is the patch http://smrt.is-a-geek.org/codeblocks/dbg_refactor/dbg_refactor0002.patch

1. The toolbar is extracted (many problems here will fix them later)
2. The watches window have been rewritten (using wxPropGrid svn r1344+, 1.4.6 won't work because it doesn't allow the user to edit the name/label of the property)

Feadback is welcome....

p.s. If the patch is hard to apply, I can split it in many smaller ones (I use git-svn, so I can provide for every commit I've done to my local repo (50+ until today))
p.s.s. wxpropgrid is not added to the source tree, I'm using the one provided by the system... you need to have it visible to the compiler/linker...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 07, 2009, 04:01:00 pm
OK,
I've done 99% of the work.
What's left:
1. The config dialogs - the current implementation should work (with no additional work), we get a multiple debugger icons in the "Settings -> Compiler & Debugger" dialog. Is that enough?
2. The debugger panel/tab in the project properties dialog - same as the above, no work and we'll get multiple tabs
3. Data breakpoints, I'll do this in a minute :)
4. Some fixes here and there
5. Do some testing on windows

I hope, I can post a patch later tonight :)
Best regards....

Edit:
p.s. Here is the latest patch: http://smrt.is-a-geek.org/codeblocks/dbg_refactor/dbg_refactor0003.patch ....
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 09, 2009, 12:58:34 am
OK, more progress

After titanic fight with the windows toolchain, a fight that I WON!
I present to you modified windows C::B http://smrt.is-a-geek.org/codeblocks/dbg_refactor/cb_new_watch_win.png

And here is a better patch http://smrt.is-a-geek.org/codeblocks/dbg_refactor/dbg_refactor0003_win_svn.patch
The previous one was impossible to apply. The current one works with Tortoise SVN's "Apply patch" (99% see below for more info)...

Could I ask the patch to be reviewed, so it can be fixed and included in trunk C::B as soon as possible? ( Morten?)

Best regards

p.s. to fully apply the patch you should move the images from plugins/debuggergdb/resources/*.png to sdk/resources/*.png
p.s.s. If the patch can't be applied I can provide an archive with the full source tree

Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on September 09, 2009, 07:09:30 am
OK, more progress

After titanic fight with the windows toolchain, a fight that I WON!
I present to you modified windows C::B http://smrt.is-a-geek.org/codeblocks/dbg_refactor/cb_new_watch_win.png

And here is a better patch http://smrt.is-a-geek.org/codeblocks/dbg_refactor/dbg_refactor0003_win_svn.patch
The previous one was impossible to apply. The current one works with Tortoise SVN's "Apply patch" (99% see below for more info)...

Could I ask the patch to be reviewed, so it can be fixed and included in trunk C::B as soon as possible? ( Morten?)

Best regards

p.s. to fully apply the patch you should move the images from plugins/debuggergdb/resources/*.png to sdk/resources/*.png
p.s.s. If the patch can't be applied a can provide an archive with the full source tree



Wonderful job!

I'll download and test in my local copy!

Thanks!!!
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 09, 2009, 11:21:14 am
And here is a better patch http://smrt.is-a-geek.org/codeblocks/dbg_refactor/dbg_refactor0003_win_svn.patch
[...]
Could I ask the patch to be reviewed, so it can be fixed and included in trunk C::B as soon as possible? ( Morten?)
Well - as guessed: The patch does not work. You have added binary data to the patch which will not work. Could you please provide me either with a patch that does not include images (the binary data) or really just send me the files (mac-fly@gmx.net will just do fine...).
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 09, 2009, 05:29:45 pm
I've not added any binary files. I've move the images from the debugger/resources/*.png to sdk/resources
Unfortunately you'll have to do the moving manually :(
The rest of the patch should work... or it fails too?

On my windows I've "patch" cmd tool installed from UnixUtils (I think) and it doesn't work :(
But tortoisesvn (apply patch applied it OK I think).

If the patches don't work I can package the whole cb tree I have and put it on my web server, is that OK?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 09, 2009, 08:41:44 pm
If the patches don't work I can package the whole cb tree I have and put it on my web server, is that OK?
The patch does not work as it contains binary data (yes - the *.patch file -> search for PNG inside).
If you want to you can put the whole source tree. Although I would prefer to have just the modified parts. But no problem if it's the whole tree. Just tell me the base SVN revision you used then.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on September 09, 2009, 09:01:24 pm
After removing the png's at the end with a text-editor (on linux), I was able to apply the patch against clean svn r5755 on windows with TortoiseSVN.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 09, 2009, 09:18:29 pm
What do you use to apply the patch?
When I used "tortoisesvn->apply patch", it told me that there are binary files but it skipped them and the rest was applied correctly (I think)

Here is the full source: http://smrt.is-a-geek.org/codeblocks/dbg_refactor/cb_dbg_refactor.zip
I prefer to send it all so it will be easier for you to do a full tree diff (I've used winmerge on windows to do it).
The source is base on r5755.

You can try this patch: http://smrt.is-a-geek.org/codeblocks/dbg_refactor/dbg_refactor0003_win_svn_no_png.patch
I've removed the pngs, don't know why they are there :(

I've tried to apply the patch with the patch command line tool on linux, but it doesn't recognised the moved files as such and keeps telling me that the patch is reversed :(

Sorry for the annoyance and the problems with the applying. :(
p.s. I've created the patch  (svn_win) with "tortoisesvn -> create patch", might that cause the problems? I can recreate it with "svn diff"
p.s.s. jens have done the same as my no_png file :)

p.s.s.s. Just to remind that you need wxPropGrid from svn in order to compile it
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 10, 2009, 08:09:56 am
p.s. I've created the patch  (svn_win) with "tortoisesvn -> create patch", might that cause the problems? I can recreate it with "svn diff"
SVN diff is always the way to prefer as this will work reliable. Actually TortoiseSVN should do the same... but it seems not.

p.s.s.s. Just to remind that you need wxPropGrid from svn in order to compile it
Ooops - just realised exactly that need.

P.s.: Instead of P.s.s.s I guess it should have read P.p.p.s ;-)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 10, 2009, 09:37:37 am
Ok... merging is (sowmehow) done. I am starting to compile now. Something I have noticed:
You also have moved resource files (XRC's) to the SDK resources but left them in the debugger, too. Doesn't this result in a conflict? Should I better remove the duplicate resources from the debugger folder (in plugins), too?

Oh - and how did you compile the propgrid from SVN? Do you use wx29 already after all? (propgrid is not part of the wx 2.8.10 sources AFAIK...)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 10, 2009, 11:03:06 am
SVN diff is always the way to prefer as this will work reliable. Actually TortoiseSVN should do the same... but it seems not.

p.s.s.s. Just to remind that you need wxPropGrid from svn in order to compile it
Ooops - just realised exactly that need.

Ok... merging is (sowmehow) done. I am starting to compile now. Something I have noticed:
You also have moved resource files (XRC's) to the SDK resources but left them in the debugger, too. Doesn't this result in a conflict? Should I better remove the duplicate resources from the debugger folder (in plugins), too?
I've move the files, so the one that are in both sdk and the debugger, should be removed from the debugger.

Oh - and how did you compile the propgrid from SVN? Do you use wx29 already after all? (propgrid is not part of the wx 2.8.10 sources AFAIK...)
I'm using wx2.8.10 + self-compiled wxpropgrid by a self-made C::B project :)
Here it is http://smrt.is-a-geek.org/codeblocks/dbg_refactor/wxpropgrid-svn.zip


P.s.: Instead of P.s.s.s I guess it should have read P.p.p.s ;-)
Thanks :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 10, 2009, 12:21:27 pm
Hmmmm...:
Code
mingw32-g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE  -DBUILDING_PLUGIN    -Iinclude -Iinclude\scripting\include -Iinclude\scripting\sqplus -IC:\Devel\wxWidgets\include -IC:\Devel\wxWidgets\lib\gcc_dll\mswu -Iinclude\wxscintilla\include -Iinclude\tinyxml -IC:\Devel\GCC4TDM\include  -c C:\Devel\CodeBlocks\src\plugins\debuggergdb\debugger_defs.cpp -o .objs\plugins\debuggergdb\debugger_defs.o
In file included from C:\Devel\CodeBlocks\src\plugins\debuggergdb\cdb_driver.cpp:12:
C:\Devel\CodeBlocks\src\plugins\debuggergdb\cdb_commands.h: In member function 'virtual void CdbCmd_Backtrace::ParseOutput(const wxString&)':
C:\Devel\CodeBlocks\src\plugins\debuggergdb\cdb_commands.h:432: error: invalid use of incomplete type 'struct cbBacktraceDlg'
C:\Devel\CodeBlocks\src\include\debuggermanager.h:17: error: forward declaration of 'struct cbBacktraceDlg'
C:\Devel\CodeBlocks\src\plugins\debuggergdb\cdb_commands.h: In member function 'virtual void CdbCmd_InfoRegisters::ParseOutput(const wxString&)':
C:\Devel\CodeBlocks\src\plugins\debuggergdb\cdb_commands.h:470: error: invalid use of incomplete type 'struct cbCPURegistersDlg'
C:\Devel\CodeBlocks\src\include\debuggermanager.h:19: error: forward declaration of 'struct cbCPURegistersDlg'
C:\Devel\CodeBlocks\src\plugins\debuggergdb\cdb_commands.h: In member function 'virtual void CdbCmd_Disassembly::ParseOutput(const wxString&)':
C:\Devel\CodeBlocks\src\plugins\debuggergdb\cdb_commands.h:504: error: invalid use of incomplete type 'struct cbDisassemblyDlg'
C:\Devel\CodeBlocks\src\include\debuggermanager.h:21: error: forward declaration of 'struct cbDisassemblyDlg'
C:\Devel\CodeBlocks\src\plugins\debuggergdb\cdb_commands.h: In member function 'virtual void CdbCmd_DisassemblyInit::ParseOutput(const wxString&)':
C:\Devel\CodeBlocks\src\plugins\debuggergdb\cdb_commands.h:554: error: invalid use of incomplete type 'struct cbDisassemblyDlg'
C:\Devel\CodeBlocks\src\include\debuggermanager.h:21: error: forward declaration of 'struct cbDisassemblyDlg'
C:\Devel\CodeBlocks\src\plugins\debuggergdb\cdb_commands.h:567: error: invalid use of incomplete type 'struct cbDisassemblyDlg'
C:\Devel\CodeBlocks\src\include\debuggermanager.h:21: error: forward declaration of 'struct cbDisassemblyDlg'
Process terminated with status 1 (0 minutes, 25 seconds)
10 errors, 1 warnings
Not sure why that is... the includes and everything looks just fine to me...?!
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 10, 2009, 02:44:35 pm
Hmmmm...:
Nah - forget about it. Still duplicate files in the debugger plugin folder that moved to SDK. It has compiled successfully!!! :D

Now let's give it a try... 8)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 10, 2009, 05:17:47 pm
Now let's give it a try... 8)
Ok - first impression:
- it works partially :)
- it does not stop at a BP
- if I enabled "evaluation expression under cursor" C::B crashes
...digging into it. (Compiler: 4.4.0 TDM, Debugger 6.8-3.)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 10, 2009, 05:58:35 pm
What are you debugging?
Is it something complex or a simple test project you can provide, so I can test too?
I've not tested it thoroughly on windows. :(
I've done a simple test and it stopped on the breakpoint (I think).
Do you see the breakpoint in the breakpoints dialog and do you see the break commands in the "debugger log (debug)" window?
Does "run to cursor" work.
"Evaluate expression" doesn't crash here, if you provide an example project I'll see what's doing on.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 10, 2009, 06:07:40 pm
What are you debugging?
I am debugging a hello world app ;-)

Do you see the breakpoint in the breakpoints dialog and do you see the break commands in the "debugger log (debug)" window?
No. I don't come that far.

"Evaluate expression" doesn't crash here, if you provide an example project I'll see what's doing on.
It was not that one but enabling the debugger's debug log (in the debuggers options).
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 10, 2009, 06:36:29 pm
It was not that one but enabling the debugger's debug log (in the debuggers options).

Crashed it too, will debug in a minute

Update: THE PATCH:

Code
diff U3 include/logmanager.h include/logmanager.h
--- include/logmanager.h Thu Jan 15 11:14:12 1970
+++ include/logmanager.h Thu Jan 15 11:14:12 1970
@@ -100,7 +100,7 @@
          *     Plugins should call Panic() with the plugin's name as the component argument.
          */
 
- void Log(const wxString& msg, int i = app_log, Logger::level lv = Logger::info) { slot[i].log->Append(msg, lv); };
+ void Log(const wxString& msg, int i = app_log, Logger::level lv = Logger::info) { cbAssert(i >= 0 && i <= max_logs); slot[i].log->Append(msg, lv); };
  void LogWarning(const wxString& msg, int i = app_log) { Log(msg, i, Logger::warning); };
  void LogError(const wxString& msg, int i = app_log) { Log(msg, i, Logger::error); };
 
diff U3 plugins/debuggergdb/debuggergdb.cpp plugins/debuggergdb/debuggergdb.cpp
--- plugins/debuggergdb/debuggergdb.cpp Thu Jan 15 11:14:12 1970
+++ plugins/debuggergdb/debuggergdb.cpp Thu Jan 15 11:14:12 1970
@@ -340,11 +340,11 @@
     if (!log_visible && m_HasDebugLog)
     {
         Manager::Get()->GetDebuggerManager()->HideLogger(true);
+        m_DbgPageIndex = -1;
     }
     else if (log_visible && !m_HasDebugLog)
     {
-        int index;
-        Manager::Get()->GetDebuggerManager()->GetLogger(true, index);
+        Manager::Get()->GetDebuggerManager()->GetLogger(true, m_DbgPageIndex);
     }
     m_HasDebugLog = log_visible;
 }
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 10, 2009, 08:38:31 pm
With the patch above, I get this error on linux:
Code
/home/obfuscated/projects/codeblocks/git/src/include/logmanager.h:103: warning: comparison between signed and unsigned integer expressions
/home/obfuscated/projects/codeblocks/git/src/include/logmanager.h:103: error: ‘cbAssert’ was not declared in this scope
Which is the best way I can fix it?

Update: the error is in my plugin which is outside of the CB tree
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 10, 2009, 09:03:25 pm
Which is the best way I can fix it?
I've attached a modified logmanager.h which I will check-in later. Please use that instead of cbAssert in that case. Cause otherwise badly written plugins will terminate C::B.

[attachment deleted by admin]
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 10, 2009, 09:27:58 pm
Morten are you sure?
I think that cbAssert does nothing in release builds?
If we have a definition of release builds :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 10, 2009, 09:52:38 pm
I think that cbAssert does nothing in release builds?
That's true. However - as we rarely doing true debug builds we would not see it anyways...

BTW: Your error: You'll need to include cbexcepton.h in logmanager.h.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 12, 2009, 03:19:22 pm
...just for the record: Everything compiles fine and seems to run fine on Windows XP. However - on Vista I get an immediate crash which has it's source in wxPropGrid. Not sure if it's a wxPropGrid bug or C::B...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 12, 2009, 08:30:45 pm
No Vista around to test it :(
Can you post the backtrace?

By the way I've found, some little bugs... will provide patch at some point :)

Another thing, what is the master plan for the application of the patch?
Test it some more and put it in trunk or a separate branch?
Or it depends on the wxpropgrid's integration in C::B's tree?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 12, 2009, 09:13:15 pm
Test it some more and put it in trunk or a separate branch?
Or it depends on the wxpropgrid's integration in C::B's tree?
We have discussed that already internally.
My proposal:
1.) integrate wxpropgrid into trunk
2.) Apply patches (already available and currently in testing phase) to update all components to new wxpropertygrid
3.) remove old one from wxsmith (to avoid conflicts)
4.) (in parallel) -> create a branch to test the new debugger stuff
5.) (if all devs agree) -> merge into trunk.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 12, 2009, 09:15:06 pm
Can you post the backtrace?
The backtrace has only addresses, no source code. I did some mods already myself. Keep posting patches quickly to avoid conflicts, please. ;-) I'll post a screenshot of the debugger session once I am ready. I seem to be a null pointer access at initialisation phase of wxproptertygrid...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 12, 2009, 09:35:37 pm
Patch 1 - RunToCursor goes to the correct line
Code
index e6a1e9a..475ae23 100644
--- a/src/sdk/debuggermenu.cpp
+++ b/src/sdk/debuggermenu.cpp
@@ -233,7 +233,7 @@ void DebuggerMenuHandler::OnRunToCursor(wxCommandEvent& event)
     if (!ed)
         return;
     const wxString &line_text = ed->GetControl()->GetLine(ed->GetControl()->GetCurrentLine());
-    m_activeDebugger->RunToCursor(ed->GetFilename(), ed->GetControl()->GetCurrentLine(), line_text);
+    m_activeDebugger->RunToCursor(ed->GetFilename(), ed->GetControl()->GetCurrentLine() + 1, line_text);
 }
 
 void DebuggerMenuHandler::OnToggleBreakpoint(wxCommandEvent& event)


Patch 2 - make writing debugger plugins easier
Code
diff --git a/src/include/cbplugin.h b/src/include/cbplugin.h
index 6f234ea..7237c07 100644
--- a/src/include/cbplugin.h
+++ b/src/include/cbplugin.h
@@ -498,6 +498,7 @@ class PLUGIN_EXPORT cbDebuggerPlugin: public cbPlugin
         virtual wxString GetEditorWordAtCaret();
     protected:
         void RemoveBreakpointFromEditor(const wxString& filename, int line);
+        void ClearActiveMarkFromAllEditors();
     private:
         wxToolBar *m_toolbar;
 };
diff --git a/src/plugins/debuggergdb/debuggergdb.cpp b/src/plugins/debuggergdb/debuggergdb.cpp
index 9b8c36d..9e34854 100644
--- a/src/plugins/debuggergdb/debuggergdb.cpp
+++ b/src/plugins/debuggergdb/debuggergdb.cpp
@@ -1774,20 +1774,6 @@ void DebuggerGDB::BringAppToFront()
         app->Raise();
 }
 
-void DebuggerGDB::ClearActiveMarkFromAllEditors()
-{
-    EditorManager* edMan = Manager::Get()->GetEditorManager();
-//  Plugins are destroyed prior to EditorManager, so this is guaranteed to be valid at all times
-//    if (!edMan)
-//        return;
-    for (int i = 0; i < edMan->GetEditorsCount(); ++i)
-    {
-        cbEditor* ed = edMan->GetBuiltinEditor(i);
-        if (ed)
-            ed->SetDebugLine(-1);
-    }
-}
-
 void DebuggerGDB::SyncEditor(const wxString& filename, int line, bool setMarker)
 {
     DebuggerManager::SyncEditorResult result;
diff --git a/src/plugins/debuggergdb/debuggergdb.h b/src/plugins/debuggergdb/debuggergdb.h
index 72703a9..ea9fa3f 100644
--- a/src/plugins/debuggergdb/debuggergdb.h
+++ b/src/plugins/debuggergdb/debuggergdb.h
@@ -116,7 +116,6 @@ class DebuggerGDB : public cbDebuggerPlugin
         void DoSwitchToDebuggingLayout();
         void DoSwitchToPreviousLayout();
         void ParseOutput(const wxString& output);
-        void ClearActiveMarkFromAllEditors();
         void DoWatches();
         wxString FindDebuggerExecutable(Compiler* compiler);
         int LaunchProcess(const wxString& cmd, const wxString& cwd);
diff --git a/src/sdk/cbplugin.cpp b/src/sdk/cbplugin.cpp
index 4f6a2e1..0650ea5 100644
--- a/src/sdk/cbplugin.cpp
+++ b/src/sdk/cbplugin.cpp
@@ -166,6 +166,20 @@ void cbDebuggerPlugin::RemoveBreakpointFromEditor(const wxString& filename, int
         ed->RemoveBreakpoint(line, false);
 }
 
+void cbDebuggerPlugin::ClearActiveMarkFromAllEditors()
+{
+    EditorManager* edMan = Manager::Get()->GetEditorManager();
+//  Plugins are destroyed prior to EditorManager, so this is guaranteed to be valid at all times
+//    if (!edMan)
+//        return;
+    for (int i = 0; i < edMan->GetEditorsCount(); ++i)
+    {
+        cbEditor* ed = edMan->GetBuiltinEditor(i);
+        if (ed)
+            ed->SetDebugLine(-1);
+    }
+}
+
 /////
 ///// cbToolPlugin
 /////


Patch 3 - the stop button behaviour has been broken  :roll:
Code
--- a/src/sdk/debuggermenu.cpp
+++ b/src/sdk/debuggermenu.cpp
@@ -190,7 +190,10 @@ void DebuggerMenuHandler::OnStart(wxCommandEvent& event)
 void DebuggerMenuHandler::OnStop(wxCommandEvent& event)
 {
     cbAssert(m_activeDebugger);
-    m_activeDebugger->Stop();
+    if(m_activeDebugger->IsStopped())
+        m_activeDebugger->Stop();
+    else
+        m_activeDebugger->Break();
 }
 
 void DebuggerMenuHandler::OnContinue(wxCommandEvent& event)

What are you changes?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 12, 2009, 10:03:37 pm
Patch 1 [...] 3
Cool. Keep 'em coming...

What are you changes?
Only minor things. Please be patient, I am in the process of preparing a branch for this... just need a couple more clean-ups. It will be way easier then...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 13, 2009, 01:08:46 am
I'm patient, just want to know what's going on, no rushing at all :)

I have no major things, to do ... just I need to implement some logic to remember last used debugger
At the moment, I'm working on my gdb/mi plugin

By the way: I've not tested the MS debugger (cdb?) at all.
Also, I've not modified the autotools files, so the build might not work :(
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 13, 2009, 02:13:26 pm
Also, I've not modified the autotools files, so the build might not work :(
i know. ;-)
Hopefully one of the linux devs will take care. Shouldn't be too hard though...

Here are major changes (FYI) that I did:
- changed the compiler #defines for wxPropGrid to make it work from within plugins, too
- changed SDK files to use sdk_precomp
- moved and integrated wxpropgrid into C::B SDK and build system
- (couple of missing includes...)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 16, 2009, 09:09:24 am
Ok - first impression:
- it works partially :)
- it does not stop at a BP
- if I enabled "evaluation expression under cursor" C::B crashes
...digging into it. (Compiler: 4.4.0 TDM, Debugger 6.8-3.)
My second expression:
- it works flawlessly.
- BP's work
- (propgrid) views work
- evaluation under cursor works.
I'll try to commit the whole stuff today to the branch. I just need to update the update scripts... :lol:
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 16, 2009, 01:41:46 pm
Whoever watches that topic: Try the wxpropgrid_debugger branch where all this is integrated and open for testing now!
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 16, 2009, 04:00:11 pm
OK, tonight I'll try it.

Quote
- updated project files and makefile system accordingly (makefile system is incomplete and needs fixing!)

This is only for the changes related to the debugger or includes other problems with the make system?
I'll try to fix it, but my autofu is quite limited :(
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on September 16, 2009, 04:05:57 pm
OK, tonight I'll try it.

Quote
- updated project files and makefile system accordingly (makefile system is incomplete and needs fixing!)

This is only for the changes related to the debugger or includes other problems with the make system?
I'll try to fix it, but my autofu is quite limited :(

I'm working on it and will commit the fixes (most likely) this evening (UTC+2) .
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 16, 2009, 04:10:54 pm
This is only for the changes related to the debugger or includes other problems with the make system?
Not only the debugger I'm afraid. And we are two now: My knowledge about autotools is limited, too as I am don'tuse Linux (Unix) very often.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: mariocup on September 16, 2009, 10:20:42 pm
Hi Martin,

I am trying to build the debugger branch, but I get the following error:

Code
src\plugins\debuggergdb\debugger_defs.h:12:22: tr1/memory: No such file or directory
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on September 16, 2009, 10:23:05 pm
Compiling the contrib-plugins workspace on linux at the moment, looks good so far.
Fix for autotolls comes, if compiling with C::B works.

By the way: if I close a project, the breakpointlist is not cleared.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 17, 2009, 09:58:42 am
Code
src\plugins\debuggergdb\debugger_defs.h:12:22: tr1/memory: No such file or directory
You need gcc4.0.0+ because I'm using std::shared_ptr<> here and there.
Morten is that a problem?

By the way: if I close a project, the breakpointlist is not cleared.
Will fix tonight, thanks for the report
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: mariocup on September 17, 2009, 10:03:40 am
Hi oBFusCATed,

some weeks ago I switched to GCC 4.4.0 but had problems building CB with auto-import if I remember correctly. I will try it again with GCC 4.4.0 tonight.

Thanks
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 17, 2009, 11:48:49 am
Morten is that a problem?
Funny that I did not realise this because I just swapped to GCC4 myself very recently. Hmmm... so far we only used 3.4.5 for official builds. But now as GCC4.0.0. is officially out we might switch, but this needs some discussion. AFAIK the nightly builds are already donw ith GCC4 (need to check that, too).
But if you are only using std::shared_ptr<> why not implementing a GCC 3.4.5 "compatibility header" similar like boost)?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on September 17, 2009, 11:59:05 am
Linux build-system is updated in debugger/propgrid-branch (C::B projectfiles and automake).

Please test and post any issues.

Thanks.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 17, 2009, 12:18:58 pm
But if you are only using std::shared_ptr<> why not implementing a GCC 3.4.5 "compatibility header" similar like boost)?
You propose to extract the shared_ptr from boost?
I can remove them. I'm using them only in std::vector<std::tr1::shared_ptr<some_type> > container_some_type.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 17, 2009, 12:56:08 pm
You propose to extract the shared_ptr from boost?
No, surely not. :-)
I meant a freely available simple (!) implementation in one header file that gets included if the GCC version is less than 4. If it makes sense to use shared pointers in your case I wouldn't want to remove that option. I need to have a look where and why exactly you need them.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 17, 2009, 08:14:40 pm
OK, I've build it with the autotools build system. (r5804)
It is now my main installation.  :lol:
Some feedback:

1. The new icons are awful ... don't like them at all (maybe I'm too used to the old ones), can we use the desktop icon theme on linux in particular, so C::B can feel more integrated?
2. The highlight occurrences is broken somehow... here is a screen shot: http://smrt.is-a-geek.org/codeblocks/cb_highlight_but.png
3. Can we have "X" images on the start up page, next to the project/workspace/file list, instead of the "X" symbol?
4. The watch windows seems to work also setting breakpoints...

One thing, I think would be cool to implement is "select something in the editor, drag&drop it on the watch window, new watch is added".
The question is where should I look for the drag&dropping thing?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on September 17, 2009, 08:33:24 pm
OK, I've build it with the autotools build system. (r5804)
It is now my main installation.  :lol:
Some feedback:

1. The new icons are awful ... don't like them at all (maybe I'm too used to the old ones), can we use the desktop icon theme on linux in particular, so C::B can feel more integrated?
2. The highlight occurrences is broken somehow... here is a screen shot: http://smrt.is-a-geek.org/codeblocks/cb_highlight_but.png
3. Can we have "X" images on the start up page, next to the project/workspace/file list, instead of the "X" symbol?
4. The watch windows seems to work also setting breakpoints...

One thing, I think would be cool to implement is "select something in the editor, drag&drop it on the watch window, new watch is added".
The question is where should I look for the drag&dropping thing?

I_m working on the second one (know the cause and fixing it) will commit later.

3. I have a working copy that uses trashcans instead of the x and I have put them in front of the line, I can provide a screenshot later.

Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on September 17, 2009, 10:33:21 pm
3. I have a working copy that uses trashcans instead of the x and I have put them in front of the line, I can provide a screenshot later.

Here it is:

[attachment deleted by admin]
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 17, 2009, 11:35:31 pm
By the way: if I close a project, the breakpointlist is not cleared.

Here is the patch for the fix: http://smrt.is-a-geek.org/codeblocks/dbg_refactor/remove_bkpt_on_prj_close.patch
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 18, 2009, 01:52:31 pm
1. The new icons are awful ...
As I said in the logs: we can provide icon sets. We would have two now. :-)

3. Can we have "X" images on the start up page, next to the project/workspace/file list, instead of the "X" symbol?
Here it is:
Cool, I like it! Submit, submit! ;-)

The question is where should I look for the drag&dropping thing?
What do you mean by that? Do you mean how D&D works in wxWidgets or C::B in particular?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 18, 2009, 01:53:55 pm
Here is the patch for the fix: http://smrt.is-a-geek.org/codeblocks/dbg_refactor/remove_bkpt_on_prj_close.patch
Works here && applied in the branch. Thanks.

One question: Do you save/restore the bookmarks "somehow"? Because I found some information related in the config file...?! Naah... I'll have a look...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on September 18, 2009, 01:59:40 pm
I just found another issue:

I set a BP in line 33, close the file and reopen it.
The list says I have a BP in line 33, but the icon appears in 34.
If I now click in the margin on line 34 nothing happens, I can not add or remove the BP-icon, if I right-click it says "edit, remove ...", but nothing happens.
If I click the margin in line 33, I get two identical entries in the BP-list and a BP-icon in 33, if I click again, both entries (and the icon) are removed.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 18, 2009, 02:15:59 pm
If I click the margin in line 33, I get two identical entries in the BP-list and a BP-icon in 33, if I click again, both entries (and the icon) are removed.
Harhar... seems we've re-introduced an old bug somehow... ;-)

Edit: What is not clear to me: Why are the BP's handled one time in m_State and another time in m_breakpoints?! There is a funny mixture of what is being used inside debuggergdb. It's not clear to me when which version is right...?!
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 18, 2009, 02:16:51 pm
Works here && applied in the branch. Thanks.
Thanks, too

One question: Do you save/restore the bookmarks "somehow"? Because I found some information related in the config file...?! Naah... I'll have a look...
If you ask about breakpoint, not bookmarks the answer is no. Also I haven't touched the bookmarks at all

I just found another issue:

I set a BP in line 33, close the file and reopen it.
The list says I have a BP in line 33, but the icon appears in 34.
If I now click in the margin on line 34 nothing happens, I can not add or remove the BP-icon, if I right-click it says "edit, remove ...", but nothing happens.
If I click the margin in line 33, I get two identical entries in the BP-list and a BP-icon in 33, if I click again, both entries (and the icon) are removed.

Thanks for the report, I'll look at it in a minute
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 18, 2009, 02:19:21 pm
Thanks for the report, I'll look at it in a minute
Please see my note in the  (edited) post before yours...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 18, 2009, 02:54:22 pm
Edit: What is not clear to me: Why are the BP's handled one time in m_State and another time in m_breakpoints?! There is a funny mixture of what is being used inside debuggergdb. It's not clear to me when which version is right...?!
I didn't want to mess with the plugin code too much. So I settled for some code duplication.

Here is the fix, but maybe I should extract this and the other notifications, so all plugins implement it by default :)
Code
Index: src/plugins/debuggergdb/debuggergdb.cpp
===================================================================
--- src/plugins/debuggergdb/debuggergdb.cpp     (revision 5809)
+++ src/plugins/debuggergdb/debuggergdb.cpp     (working copy)
@@ -2008,7 +2008,7 @@
             bpFileName.Normalize();
             edFileName.Normalize();
             if (bpFileName.GetFullPath().Matches(edFileName.GetFullPath()))
-                ed->ToggleBreakpoint(bp->line, false);
+                ed->ToggleBreakpoint(bp->line - 1, false);
         }
         // Now check and highlight the active line under debugging
         if (m_State.HasDriver())
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on September 18, 2009, 03:02:44 pm
The patch works, but ...

If I add a BP with the context-menu it does not appear in the list, if I then add another BP with a left-click in the margin, both are listed.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 18, 2009, 03:48:14 pm
I didn't want to mess with the plugin code too much. So I settled for some code duplication.
I understand why, but I think we seriously need to clean that up. In the past we had watches, breakpoints in the driver and needed to "synch" them with the BP's (in the editors). It was already confusing as the editors have a different indexing (an editor starts with line 1, a BP with line 0). Now that we have watches and BP's duplicated in the debugger, too we need to take care to "synch" 5 instances. This will lead to a lot of errors like Jens is experiencing.

If you realise that the "driver" is actually the instance of the debugger I think it's most plausible to keep the implementation in the "state" and remove it again from the debugger instance.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 18, 2009, 04:00:06 pm
If I add a BP with the context-menu it does not appear in the list, if I then add another BP with a left-click in the margin, both are listed.
I fixed that, too and committed both fixes to the branch.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 18, 2009, 09:56:49 pm
I understand why, but I think we seriously need to clean that up. In the past we had watches, breakpoints in the driver and needed to "synch" them with the BP's (in the editors). It was already confusing as the editors have a different indexing (an editor starts with line 1, a BP with line 0). Now that we have watches and BP's duplicated in the debugger, too we need to take care to "synch" 5 instances. This will lead to a lot of errors like Jens is experiencing.

If you realise that the "driver" is actually the instance of the debugger I think it's most plausible to keep the implementation in the "state" and remove it again from the debugger instance.

Are you sure about that the editor starts at 1, my observations are that it starts at 0.
I think, I made the debugger breakpoints to start from 1.

For me the gdb/cdb debuggers should be split in two separate plugins.
I've started the implementation of the gdb only plugin (using the MI interface).

And another thing: the duplication is needed because the outside world, should not see the implementation details (the temporary breakpoint in the current example)

p.s. this bug are caused by the late redesign of the breakpoints interface I made, so I'm sorry for the cases I've not tested
p.p.s. I can do the redesign to remove the duplication, but I'm sure I'll break more staff than that cause by the duplication
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: mariocup on September 20, 2009, 01:03:31 am
Hi oBFusCATed,

I just had a look at your debugger modifications and the watch window is nice. I would prefer the same view also for the CPU register window  (with switching of the display format too) with the possibility to edit values.
For embedded controller I see the necessity to edit values of the CPU registers or memory (view) etc. Do you intend to modify also these components.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 20, 2009, 01:40:47 am
I could do it some day, but I've never used the CPU registers window, so I have very little motivation to do it.
I'm using the memory window more often, so there is bigger chance for improvements there.

But you never, know if I have nothing to do I can do it.
Also I think the modifications should be made by a person using the window, because he/she would know what is important and what not.

Best regards...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 30, 2009, 11:35:40 pm
Here is a patch that fixes the parsing the GDB output, generated by "output var", when "var" is a reference.

Code
Index: src/plugins/debuggergdb/parsewatchvalue.cpp
===================================================================
--- src/plugins/debuggergdb/parsewatchvalue.cpp (revision 5826)
+++ src/plugins/debuggergdb/parsewatchvalue.cpp (working copy)
@@ -314,12 +314,20 @@
         return true;
     }
 
-    if(value[0] == wxT('{') && value[value.length() - 1] == wxT('}'))
+    // Try to find the first brace.
+    // If the watch is for a reference the brace is not at position = 0
+    wxString::size_type start = value.find(wxT('{'));
+
+    if(start != wxString::npos && value[value.length() - 1] == wxT('}'))
     {
-        int start = 1;
-        bool result = ParseGDBWatchValue(watch, value, start, value.length() - 2);
+        int t_start = start + 1;
+        bool result = ParseGDBWatchValue(watch, value, t_start, value.length() - 2);
         if(result)
+        {
+            if(start > 0)
+                watch.SetValue(value.substr(0, start));
             watch.RemoveChildren(true);
+        }
         return result;
     }
     else
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on October 02, 2009, 01:57:55 am
Here is another patch, that tries to fix various breakpoint problems and little bugs

http://smrt.is-a-geek.org/codeblocks/dbg_refactor/fix_breakpoints.patch
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on October 02, 2009, 03:26:04 am
http://smrt.is-a-geek.org/codeblocks/dbg_refactor/fix_breakpoints.patch
Mmmmh... I cannot apply this patch. Nearly everything is rejected. Did you use svn diff to create the patch? If not, please try that.

Just do:
svn diff > the_patch.patch
...in the SVN controlled root folder of C::B.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: eranif on October 02, 2009, 06:44:49 am
Here is another patch, that tries to fix various breakpoint problems and little bugs

http://smrt.is-a-geek.org/codeblocks/dbg_refactor/fix_breakpoints.patch

Wanted to give you a "heads-up":
The debugger wont work as expected on MacOSX since GDB/MI returns different output then Linux/Windows (the format is a bit different)
So you might want to test it on Mac as well to fix the parsing.

Eran

Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on October 02, 2009, 06:58:06 am
So you might want to test it on Mac as well to fix the parsing.
Good catch, Eran. Hence we have literally no active developer that owns a MAC... so it will be a hard task.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on October 02, 2009, 08:22:56 am
Mmmmh... I cannot apply this patch. Nearly everything is rejected. Did you use svn diff to create the patch? If not, please try that.

Just do:
svn diff > the_patch.patch
...in the SVN controlled root folder of C::B.
Arghhh.... the patch is created with svn diff and applies correctly on my machine (I have a gentoo ebuild (package) for svn that uses it)

Wanted to give you a "heads-up":
The debugger wont work as expected on MacOSX since GDB/MI returns different output then Linux/Windows (the format is a bit different)
So you might want to test it on Mac as well to fix the parsing.

Eran
Thanks, Eran I plan to install hackosx 10.6 when there is a proper distro for my machine, so I hope I can do some testing
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on October 02, 2009, 09:41:41 am
Code
-------------- Build: Debugger in Code::Blocks ---------------

mingw32-g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE  -DBUILDING_PLUGIN -DWXMAKINGDLL_PROPGRID -DwxPG_USE_WXMODULE=0    -IC:\wxWidgets-2.8.10\include -IC:\wxWidgets-2.8.10\contrib\include -IC:\wxWidgets-2.8.10\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Isdk\wxpropgrid\include -Iinclude\tinyxml -Iinclude -Iinclude\scripting\include -Iinclude\scripting\sqplus  -c C:\cb_debugger_branch\src\plugins\debuggergdb\cdb_driver.cpp -o .objs\plugins\debuggergdb\cdb_driver.o
mingw32-g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE  -DBUILDING_PLUGIN -DWXMAKINGDLL_PROPGRID -DwxPG_USE_WXMODULE=0    -IC:\wxWidgets-2.8.10\include -IC:\wxWidgets-2.8.10\contrib\include -IC:\wxWidgets-2.8.10\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Isdk\wxpropgrid\include -Iinclude\tinyxml -Iinclude -Iinclude\scripting\include -Iinclude\scripting\sqplus  -c C:\cb_debugger_branch\src\plugins\debuggergdb\databreakpointdlg.cpp -o .objs\plugins\debuggergdb\databreakpointdlg.o
mingw32-g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE  -DBUILDING_PLUGIN -DWXMAKINGDLL_PROPGRID -DwxPG_USE_WXMODULE=0    -IC:\wxWidgets-2.8.10\include -IC:\wxWidgets-2.8.10\contrib\include -IC:\wxWidgets-2.8.10\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Isdk\wxpropgrid\include -Iinclude\tinyxml -Iinclude -Iinclude\scripting\include -Iinclude\scripting\sqplus  -c C:\cb_debugger_branch\src\plugins\debuggergdb\debugger_defs.cpp -o .objs\plugins\debuggergdb\debugger_defs.o
mingw32-g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE  -DBUILDING_PLUGIN -DWXMAKINGDLL_PROPGRID -DwxPG_USE_WXMODULE=0    -IC:\wxWidgets-2.8.10\include -IC:\wxWidgets-2.8.10\contrib\include -IC:\wxWidgets-2.8.10\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Isdk\wxpropgrid\include -Iinclude\tinyxml -Iinclude -Iinclude\scripting\include -Iinclude\scripting\sqplus  -c C:\cb_debugger_branch\src\plugins\debuggergdb\debuggerdriver.cpp -o .objs\plugins\debuggergdb\debuggerdriver.o
mingw32-g++.exe -Wall -g -pipe -mthreads -fmessage-length=0 -fexceptions -Winvalid-pch -DHAVE_W32API_H -D__WXMSW__ -DWXUSINGDLL -DcbDEBUG -DCB_PRECOMP -DWX_PRECOMP -DwxUSE_UNICODE  -DBUILDING_PLUGIN -DWXMAKINGDLL_PROPGRID -DwxPG_USE_WXMODULE=0    -IC:\wxWidgets-2.8.10\include -IC:\wxWidgets-2.8.10\contrib\include -IC:\wxWidgets-2.8.10\lib\gcc_dll\mswu -Isdk\wxscintilla\include -Isdk\wxpropgrid\include -Iinclude\tinyxml -Iinclude -Iinclude\scripting\include -Iinclude\scripting\sqplus  -c C:\cb_debugger_branch\src\plugins\debuggergdb\debuggergdb.cpp -o .objs\plugins\debuggergdb\debuggergdb.o
C:\cb_debugger_branch\src\plugins\debuggergdb\debuggergdb.cpp:1748:1: error: unterminated #ifndef
C:\cb_debugger_branch\src\plugins\debuggergdb\debuggergdb.cpp: In member function 'virtual void DebuggerGDB::Break()':
C:\cb_debugger_branch\src\plugins\debuggergdb\debuggergdb.cpp:1747: warning: unused variable 'pid'
C:\cb_debugger_branch\src\plugins\debuggergdb\debuggergdb.cpp:1747: error: expected '}' at end of input
C:\cb_debugger_branch\src\plugins\debuggergdb\debuggergdb.cpp:1747: error: expected '}' at end of input
Process terminated with status 1 (12 minutes, 40 seconds)
3 errors, 9 warnings
 

build failed in the latest debugger branch under TDM mingw.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on October 02, 2009, 09:46:38 am
Olly: try the patch http://smrt.is-a-geek.org/codeblocks/dbg_refactor/fix_breakpoints.patch
It should have fix for it.
There was another build failure in the scintilla code... some usage of UINT which failed on linux.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on October 02, 2009, 10:43:46 am
Olly: try the patch http://smrt.is-a-geek.org/codeblocks/dbg_refactor/fix_breakpoints.patch
It should have fix for it.
There was another build failure in the scintilla code... some usage of UINT which failed on linux.
Thanks, after applying the patch, it build successfully.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on October 02, 2009, 12:21:12 pm
Olly: try the patch http://smrt.is-a-geek.org/codeblocks/dbg_refactor/fix_breakpoints.patch
Mmmmh... here at work applying the patch works...?! I'll have a look at it finally... ;-)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on October 04, 2009, 08:46:31 pm
Morten do you have some time to apply the last patch?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on October 04, 2009, 09:25:14 pm
Morten do you have some time to apply the last patch?
Once I am back at a PC with C::B... ;-)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on October 15, 2009, 11:02:37 pm
Here is another patch for the debugger: http://smrt.is-a-geek.org/codeblocks/dbg_refactor/dbg_refactor0004.patch

What it does:
1. Improvements to the backtrace window - the inactive stack frames are not shown as "??" any more
2. Fixed bug https://developer.berlios.de/bugs/?func=detailbug&bug_id=16146&group_id=5358
3. Some cleaning

Best regards
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on October 19, 2009, 12:43:56 am
Yet another patch http://smrt.is-a-geek.org/codeblocks/dbg_refactor/dbg_refactor0005.patch
This one includes the changes from the previous one plus:

1. Fixed bug 13972 ( http://developer.berlios.de/bugs/?func=detailbug&bug_id=13972&group_id=5358 )
2. Modified one of the regexpr for matching lines of the backtrace (case #0)
3. Added two menu options to choose the default action on double click in the backtrace window ("jump to" or "switch to")

Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on October 19, 2009, 03:43:27 am
Hi, oBF, thanks!!!!! :D

I just apply this patch, and find a small bug.

The test code is the attachment of this message
http://forums.codeblocks.org/index.php/topic,11301.msg77123.html#msg77123

In debugger branch, I can set breakpoint in the function body.

Code
void __declspec(dllexport) MyFunction(const LPCSTR sometext)
{
    /** SET BREAK POINT HERE VVVVVVVVVVV **/
    MessageBoxA(0, sometext, "DLL Message", MB_OK | MB_ICONINFORMATION); *************breakpoint set here.
    /** SET BREAK POINT HERE ^^^^^^^^^^^^ **/
}

when the debugger hit the bp, cursor jumped to the wrong place,
Code
        if ( NULL != ProcAdd )
            {
            fRunTimeLinkSuccess = TRUE;
            ( ProcAdd ) ( TEXT( "Message via DLL function\n" ) ); *********when bp hit, the cursor always jump here.
            }

I think this is wrong behavior.

It works fine in the trunk version.

My environment: TDM-MinGW GCC 4.4.1 and GDB 7.02
and with patch from jens:
http://forums.codeblocks.org/index.php/topic,11301.msg77156.html#msg77156

thanks.


Edit


I just found that if the Call stack window was not opened during debugging, the cursor can jump to the right place. :D, so, this is an issue of interpreting the backtrack output.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on October 19, 2009, 09:35:28 am
Uau, you are quite fast :)

Can you provide a platform independent test case? (probably not because I'm sure it breaks because of the "__declspec(dllexport)" )
Can you paste here the output in the debugger log window after the "bt 30" command..
Unfortunately the output of that command is made for users not parsers and so it is quite unreliable :(

Thanks for the feadback

Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on October 19, 2009, 01:49:21 pm
Uau, you are quite fast :)

Can you provide a platform independent test case? (probably not because I'm sure it breaks because of the "__declspec(dllexport)" )
Can you paste here the output in the debugger log window after the "bt 30" command..
Unfortunately the output of that command is made for users not parsers and so it is quite unreliable :(

Thanks for the feadback



Ok, but I can only supply a windows test case, because I only have windows. I haven't tried linux till now. :(

Log with no call stack window:
Code
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb (GDB) 7.0
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
>>>>>>cb_gdb:
> set confirm off
>>>>>>cb_gdb:
> set width 0
>>>>>>cb_gdb:
> set height 0
>>>>>>cb_gdb:
> set breakpoint pending on
>>>>>>cb_gdb:
> set print asm-demangle on
>>>>>>cb_gdb:
> set unwindonsignal on
>>>>>>cb_gdb:
> set debugevents on
>>>>>>cb_gdb:
> set disassembly-flavor att
>>>>>>cb_gdb:
> catch throw
Function "__cxa_throw" not defined.
Catchpoint 1 (throw)
>>>>>>cb_gdb:
> source F:\debugger_branch\src\output\share\codeblocks/scripts/stl-views-1.0.3.gdb
>>>>>>cb_gdb:
> directory D:/codeblocks_opencv/call_DLL_wxDebugTest/
>>>>>>cb_gdb:
> break "D:/codeblocks_opencv/call_DLL_wxDebugTest/TestApp/main.cpp:63"
Breakpoint 2 at 0x401438: file D:\codeblocks_opencv\call_DLL_wxDebugTest\TestApp\main.cpp, line 63.
>>>>>>cb_gdb:
> break "D:/codeblocks_opencv/call_DLL_wxDebugTest/TestDLL/dllmain.cpp:10"
No source file named D:/codeblocks_opencv/call_DLL_wxDebugTest/TestDLL/dllmain.cpp.
Breakpoint 3 ("D:/codeblocks_opencv/call_DLL_wxDebugTest/TestDLL/dllmain.cpp:10) pending.
>>>>>>cb_gdb:
> run
gdb: windows_init_thread_list
[New Thread 1844.0x260]
[New Thread 1844.0x2c8]
Breakpoint 2, WinMain@16 (hThisInstance=0x400000, hPrevInstance=0x0, lpszArgument=0x251f1a "", nCmdShow=10) at D:\codeblocks_opencv\call_DLL_wxDebugTest\TestApp\main.cpp:63
D:\codeblocks_opencv\call_DLL_wxDebugTest\TestApp\main.cpp:63:2773:beg:0x401438
Current language:  auto
The current source language is "auto; currently c++".
>>>>>>cb_gdb:
> set debugevents off
>>>>>>cb_gdb:
> whatis szClassName
type = char [21]
>>>>>>cb_gdb:
> output &szClassName
(char (*)[21]) 0x402000>>>>>>cb_gdb:
> output szClassName
"CodeBlocksWindowsApp">>>>>>cb_gdb:
> cont
Breakpoint 3, MyFunction (sometext=0x40305d "Message via DLL function\n") at D:\codeblocks_opencv\call_DLL_wxDebugTest\TestDLL\dllmain.cpp:10
D:\codeblocks_opencv\call_DLL_wxDebugTest\TestDLL\dllmain.cpp:10:192:beg:0x684c11de
>>>>>>cb_gdb:
> cont
warning: Temporarily disabling breakpoints for unloaded shared library "D:\codeblocks_opencv\call_DLL_wxDebugTest\bin\TestDLL.dll"
Program exited normally.
>>>>>>cb_gdb:
> quit

Log with call stack window opened.
Code
> bt 30
#0  WinMain@16 (hThisInstance=0x400000, hPrevInstance=0x0, lpszArgument=0x251f1a "", nCmdShow=10) at D:\codeblocks_opencv\call_DLL_wxDebugTest\TestApp\main.cpp:63
#1  0x00401a86 in main ()
>>>>>>cb_gdb:
> break "D:/codeblocks_opencv/call_DLL_wxDebugTest/TestApp/main.cpp:65"
Breakpoint 4 at 0x40143d: file D:\codeblocks_opencv\call_DLL_wxDebugTest\TestApp\main.cpp, line 65.
>>>>>>cb_gdb:
> cont
Breakpoint 3, MyFunction (sometext=0x40305d "Message via DLL function\n") at D:\codeblocks_opencv\call_DLL_wxDebugTest\TestDLL\dllmain.cpp:10
D:\codeblocks_opencv\call_DLL_wxDebugTest\TestDLL\dllmain.cpp:10:192:beg:0x684c11de
>>>>>>cb_gdb:
> bt 30
#0  MyFunction (sometext=0x40305d "Message via DLL function\n") at D:\codeblocks_opencv\call_DLL_wxDebugTest\TestDLL\dllmain.cpp:10
#1  0x0040156b in LoadDllPlugin () at D:\codeblocks_opencv\call_DLL_wxDebugTest\TestApp\main.cpp:127
#2  0x0040143d in WinMain@16 (hThisInstance=0x400000, hPrevInstance=0x0, lpszArgument=0x251f1a "", nCmdShow=10) at D:\codeblocks_opencv\call_DLL_wxDebugTest\TestApp\main.cpp:63
#3  0x00401a86 in main ()
>>>>>>cb_gdb:
> frame 1
#1  0x0040156b in LoadDllPlugin () at D:\codeblocks_opencv\call_DLL_wxDebugTest\TestApp\main.cpp:127
D:\codeblocks_opencv\call_DLL_wxDebugTest\TestApp\main.cpp:127:4719:beg:0x40156b
>>>>>>cb_gdb:
> bt 30
#0  MyFunction (sometext=0x40305d "Message via DLL function\n") at D:\codeblocks_opencv\call_DLL_wxDebugTest\TestDLL\dllmain.cpp:10
#1  0x0040156b in LoadDllPlugin () at D:\codeblocks_opencv\call_DLL_wxDebugTest\TestApp\main.cpp:127
#2  0x0040143d in WinMain@16 (hThisInstance=0x400000, hPrevInstance=0x0, lpszArgument=0x251f1a "", nCmdShow=10) at D:\codeblocks_opencv\call_DLL_wxDebugTest\TestApp\main.cpp:63
#3  0x00401a86 in main ()
>>>>>>cb_gdb:
> frame 1
#1  0x0040156b in LoadDllPlugin () at D:\codeblocks_opencv\call_DLL_wxDebugTest\TestApp\main.cpp:127
D:\codeblocks_opencv\call_DLL_wxDebugTest\TestApp\main.cpp:127:4719:beg:0x40156b
>>>>>>cb_gdb:
> cont
warning: Temporarily disabling breakpoints for unloaded shared library "D:\codeblocks_opencv\call_DLL_wxDebugTest\bin\TestDLL.dll"
Breakpoint 4, WinMain@16 (hThisInstance=0x400000, hPrevInstance=0x0, lpszArgument=0x251f1a "", nCmdShow=10) at D:\codeblocks_opencv\call_DLL_wxDebugTest\TestApp\main.cpp:65
D:\codeblocks_opencv\call_DLL_wxDebugTest\TestApp\main.cpp:65:2799:beg:0x40143d
>>>>>>cb_gdb:
> bt 30
#0  WinMain@16 (hThisInstance=0x400000, hPrevInstance=0x0, lpszArgument=0x251f1a "", nCmdShow=10) at D:\codeblocks_opencv\call_DLL_wxDebugTest\TestApp\main.cpp:65
#1  0x00401a86 in main ()
>>>>>>cb_gdb:
> cont
Program exited normally.
>>>>>>cb_gdb:
> quit
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on October 19, 2009, 02:33:00 pm
Log with call stack window opened.
Code
> bt 30
#0  WinMain@16 (hThisInstance=0x400000, hPrevInstance=0x0, lpszArgument=0x251f1a "", nCmdShow=10) at D:\codeblocks_opencv\call_DLL_wxDebugTest\TestApp\main.cpp:63
#1  0x00401a86 in main ()

> bt 30
#0  MyFunction (sometext=0x40305d "Message via DLL function\n") at D:\codeblocks_opencv\call_DLL_wxDebugTest\TestDLL\dllmain.cpp:10
#1  0x0040156b in LoadDllPlugin () at D:\codeblocks_opencv\call_DLL_wxDebugTest\TestApp\main.cpp:127
#2  0x0040143d in WinMain@16 (hThisInstance=0x400000, hPrevInstance=0x0, lpszArgument=0x251f1a "", nCmdShow=10) at D:\codeblocks_opencv\call_DLL_wxDebugTest\TestApp\main.cpp:63
#3  0x00401a86 in main ()

> bt 30
#0  MyFunction (sometext=0x40305d "Message via DLL function\n") at D:\codeblocks_opencv\call_DLL_wxDebugTest\TestDLL\dllmain.cpp:10
#1  0x0040156b in LoadDllPlugin () at D:\codeblocks_opencv\call_DLL_wxDebugTest\TestApp\main.cpp:127
#2  0x0040143d in WinMain@16 (hThisInstance=0x400000, hPrevInstance=0x0, lpszArgument=0x251f1a "", nCmdShow=10) at D:\codeblocks_opencv\call_DLL_wxDebugTest\TestApp\main.cpp:63
#3  0x00401a86 in main ()

> bt 30
#0  WinMain@16 (hThisInstance=0x400000, hPrevInstance=0x0, lpszArgument=0x251f1a "", nCmdShow=10) at D:\codeblocks_opencv\call_DLL_wxDebugTest\TestApp\main.cpp:65
#1  0x00401a86 in main ()

That is the relevant output, I'll fix it tonight, when I get home.

Update:

Here is the fixed patch http://smrt.is-a-geek.org/codeblocks/dbg_refactor/dbg_refactor0006.patch

And the diff of the two patches
Code
--- dbg_refactor0005.patch      2009-10-19 01:26:10.000000000 +0300
+++ dbg_refactor0006.patch      2009-10-19 19:52:09.000000000 +0300
@@ -406,7 +406,7 @@
  //#31 0x004076ca in main () at C:/Devel/wxWidgets-2.6.1/include/wx/intl.h:555
  //#50  0x00410c8c in one::~one() (this=0x3d24c8) at main.cpp:14
 -static wxRegEx reBT0(_T("#([0-9]+)[ \t]+([^(]+)[ \t]+(\\([^)]*\\))")); // case #0
-+static wxRegEx reBT0(_T("#([0-9]+)[ \t]+([a-zA-Z:\\(\\)0-9 ,=_@]+)[ \t]at[ \t](.+):([0-9]+)")); // case #0
++static wxRegEx reBT0(_T("#([0-9]+)[ \t]+(.+)[ \t]at[ \t](.+):([0-9]+)")); // case #0
  static wxRegEx reBT1(_T("#([0-9]+)[ \t]+0x([A-Fa-f0-9]+)[ \t]+in[ \t]+(.+)[ \t]+(\\([^)]*\\))[ \t]")); // all other cases (gdb 6.3)
  static wxRegEx reBTX(_T("#([0-9]+)[ \t]+0x([A-Fa-f0-9]+)[ \t]+in[ \t]+([^(]+)[ \t]*(\\([^)]*\\)[ \t]*\\([^)]*\\))")); // all other cases (gdb 5.2)
  static wxRegEx reBT2(_T("\\)[ \t]+[atfrom]+[ \t]+(.*):([0-9]+)"));

UPDATE: Olly have you tried the new patch?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on October 21, 2009, 04:08:18 am
Quote
UPDATE:  Olly have you tried the new patch?

Oh my God, you just update your original post and I'm just waiting for a new notification email from this thread.
So, it's late.
I will tested it soon!
Thanks.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on October 21, 2009, 04:21:06 am
Quote
Update:

Here is the fixed patch http://smrt.is-a-geek.org/codeblocks/dbg_refactor/dbg_refactor0006.patch

I just apply this patch, and the problem is fixed  :D.

Thanks for your effort!!!
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on October 21, 2009, 09:55:02 am
Thanks, next time I'll use new post for such things.

Morten, can you apply it?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on October 21, 2009, 10:29:45 am
Morten, can you apply it?
I applied it (as of today) in my local copy... Give me some time for testing and then I'll be happy to submit to the branch.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: stahta01 on October 22, 2009, 04:46:19 pm
Patch needed on branch wxpropgrid_debugger under windows without Precompiled Headers enabled.

Tim S.

SDK folder only patch
Code
Index: src/sdk/examinememorydlg.cpp
===================================================================
--- src/sdk/examinememorydlg.cpp (revision 5882)
+++ src/sdk/examinememorydlg.cpp (working copy)
@@ -7,7 +7,11 @@
  * $HeadURL$
  */
 
-#include <sdk.h>
+#include "sdk_precomp.h"
+#ifndef CB_PRECOMP
+    #include "cbplugin.h"
+#endif
+
 #include "examinememorydlg.h"
 #include <wx/intl.h>
 #include <wx/xrc/xmlres.h>
Index: src/sdk/debuggermanager.cpp
===================================================================
--- src/sdk/debuggermanager.cpp (revision 5882)
+++ src/sdk/debuggermanager.cpp (working copy)
@@ -8,7 +8,26 @@
  */
 
 #include "sdk_precomp.h"
+#ifndef CB_PRECOMP
+    #include <wx/artprov.h>
+    #include <wx/bmpbuttn.h>
+    #include <wx/combobox.h>
+    #include <wx/filedlg.h>
+    #include <wx/frame.h>
+    #include <wx/menu.h>
+    #include <wx/sizer.h>
+    #include <wx/stattext.h>
 
+    #include "cbeditor.h"
+    #include "cbexception.h"
+    #include "cbplugin.h"
+    #include "cbproject.h"
+    #include "configmanager.h"
+    #include "editormanager.h"
+    #include "logmanager.h"
+    #include "projectmanager.h"
+#endif
+
 #include <algorithm>
 #include <wx/toolbar.h>
 
Index: src/sdk/cbplugin.cpp
===================================================================
--- src/sdk/cbplugin.cpp (revision 5882)
+++ src/sdk/cbplugin.cpp (working copy)
@@ -19,6 +19,9 @@
     #include "projectbuildtarget.h"
     #include "cbproject.h"
     #include "logmanager.h"
+    #include "editormanager.h"
+    #include "cbeditor.h"
+    #include "projectmanager.h"
 #endif
 
 #include <wx/toolbar.h>
Index: src/sdk/backtracedlg.cpp
===================================================================
--- src/sdk/backtracedlg.cpp (revision 5882)
+++ src/sdk/backtracedlg.cpp (working copy)
@@ -7,13 +7,23 @@
  * $HeadURL$
  */
 #include "sdk_precomp.h"
+#ifndef CB_PRECOMP
+    #include <wx/filedlg.h>
+    #include <wx/listctrl.h>
+    #include <wx/menu.h>
+    #include <wx/sizer.h>
+    #include <wx/txtstrm.h>
+    #include <wx/wfstream.h>
 
-#include "backtracedlg.h"
+    #include "cbplugin.h"
+    #include "configmanager.h"
+#endif
 
 #include <wx/clipbrd.h>
-#include <wx/listctrl.h>
 #include "filefilters.h"
 
+#include "backtracedlg.h"
+
 namespace
 {
     const int idList = wxNewId();
Index: src/sdk/editbreakpointdlg.cpp
===================================================================
--- src/sdk/editbreakpointdlg.cpp (revision 5882)
+++ src/sdk/editbreakpointdlg.cpp (working copy)
@@ -8,7 +8,12 @@
  */
 
 #include "sdk_precomp.h"
+#ifndef CB_PRECOMP
+    #include <wx/xrc/xmlres.h>
 
+    #include "debuggermanager.h"
+#endif
+
 #include "editbreakpointdlg.h"
 #include <wx/intl.h>
 #include <wx/xrc/xmlres.h>
Index: src/sdk/breakpointsdlg.cpp
===================================================================
--- src/sdk/breakpointsdlg.cpp (revision 5882)
+++ src/sdk/breakpointsdlg.cpp (working copy)
@@ -7,15 +7,18 @@
  * $HeadURL$
  */
 
+#include <set>
+
 #include "sdk_precomp.h"
 
-#include "breakpointsdlg.h"
-
 #ifndef CB_PRECOMP
 #   include "globals.h"
 #   include "manager.h"
 #   include "editormanager.h"
 #   include "cbeditor.h"
+#   include "cbplugin.h"
+#   include "debuggermanager.h"
+
 #   include <wx/button.h>
 #   include <wx/checkbox.h>
 #   include <wx/intl.h>
@@ -24,10 +27,13 @@
 #   include <wx/menu.h>
 #   include <wx/textctrl.h>
 #   include <wx/spinctrl.h>
+#   include <wx/sizer.h>
 #endif
 
 #include "editbreakpointdlg.h"
 
+#include "breakpointsdlg.h"
+
 namespace
 {
  const int idList = wxNewId();
Index: src/sdk/debuggermenu.cpp
===================================================================
--- src/sdk/debuggermenu.cpp (revision 5882)
+++ src/sdk/debuggermenu.cpp (working copy)
@@ -7,7 +7,15 @@
  * $HeadURL$
  */
 #include "sdk_precomp.h"
+#ifndef CB_PRECOMP
+    #include <wx/xrc/xmlres.h>
 
+    #include "cbeditor.h"
+    #include "cbproject.h"
+    #include "editormanager.h"
+    #include "projectmanager.h"
+#endif
+
 #include "debuggermenu.h"
 
 #include <algorithm>
Index: src/sdk/threadsdlg.cpp
===================================================================
--- src/sdk/threadsdlg.cpp (revision 5882)
+++ src/sdk/threadsdlg.cpp (working copy)
@@ -7,16 +7,17 @@
  * $HeadURL$
  */
 
-#include "threadsdlg.h"
+#include "sdk_precomp.h"
+#ifndef CB_PRECOMP
+    #include <wx/listctrl.h>
+    #include <wx/menu.h>
+    #include <wx/sizer.h>
 
-#include "sdk.h"
+    #include "cbplugin.h"
+#endif
 
-#include <wx/listctrl.h>
-#include <wx/menu.h>
-#include <wx/sizer.h>
+#include "threadsdlg.h"
 
-
-
 namespace
 {
     const int idList = wxNewId();
Index: src/sdk/watchesdlg.cpp
===================================================================
--- src/sdk/watchesdlg.cpp (revision 5882)
+++ src/sdk/watchesdlg.cpp (working copy)
@@ -7,11 +7,20 @@
  * $HeadURL$
  */
 
-#include <sdk.h>
-#include "watchesdlg.h"
+#include "sdk_precomp.h"
+#ifndef CB_PRECOMP
+    #include <wx/menu.h>
+    #include <wx/sizer.h>
 
+    #include "cbplugin.h"
+    #include "logmanager.h"
+    #include "scrollingdialog.h"
+#endif
+
 #include <wx/propgrid/propgrid.h>
 
+#include "watchesdlg.h"
+
 namespace
 {
     const int idGrid = wxNewId();
Index: src/include/debuggermenu.h
===================================================================
--- src/include/debuggermenu.h (revision 5882)
+++ src/include/debuggermenu.h (working copy)
@@ -6,7 +6,10 @@
 #ifndef X_DEBUGGER_MENU_H
 #define X_DEBUGGER_MENU_H
 
+#include <wx/event.h>
+
 class cbDebuggerPlugin;
+class wxToolBar;
 
 class DebuggerMenuHandler : public wxEvtHandler
 {
Index: src/include/breakpointsdlg.h
===================================================================
--- src/include/breakpointsdlg.h (revision 5882)
+++ src/include/breakpointsdlg.h (working copy)
@@ -6,8 +6,13 @@
 #ifndef BREAKPOINTSDLG_H
 #define BREAKPOINTSDLG_H
 
+#include <vector>
+
 #include <wx/panel.h>
 
+class cbBreakpoint;
+class CodeBlocksEvent;
+class cbDebuggerPlugin;
 class wxCommandEvent;
 class wxListCtrl;
 class wxListEvent;
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: stahta01 on October 23, 2009, 05:50:45 pm
Patch for src and debug plugin headers needed for NON precompiled under Windows XP.

Note: I redid the headers alot in debuggergdb.cpp in order to precompilied header sdk.h better.

Tim S.

Code
Index: src/plugins/debuggergdb/debuggergdb.cpp
===================================================================
--- src/plugins/debuggergdb/debuggergdb.cpp (revision 5883)
+++ src/plugins/debuggergdb/debuggergdb.cpp (working copy)
@@ -7,57 +7,59 @@
  * $HeadURL$
  */
 
+
 #include <sdk.h>
-#include <wx/txtstrm.h>
-#include <wx/regex.h>
-#include "scrollingdialog.h"
-#include <wx/msgdlg.h>
-#include <wx/tokenzr.h>
+#include <algorithm>  // std::remove_if
+#ifndef CB_PRECOMP
+    #include <wx/frame.h> // GetMenuBar
+    #include <wx/msgdlg.h>
+    #include <wx/regex.h>
+    #include <wx/txtstrm.h>
 
-#include <manager.h>
-#include <configmanager.h>
-#include <logmanager.h>
-#include <projectmanager.h>
-#include <pluginmanager.h>
-#include <editormanager.h>
-#include <macrosmanager.h>
-#include <cbeditor.h>
-#include <projectbuildtarget.h>
-#include <sdk_events.h>
-#include <editarraystringdlg.h>
-#include <compilerfactory.h>
-#include <projectloader_hooks.h>
-#include <xtra_res.h>
+    #include <cbeditor.h>
+    #include <cbproject.h>
+    #include <compilerfactory.h>
+    #include <configmanager.h>
+    #include <editormanager.h>
+    #include <globals.h>
+    #include <logmanager.h>
+    #include <macrosmanager.h>
+    #include <manager.h>
+    #include <pluginmanager.h>
+    #include <projectbuildtarget.h>
+    #include <projectmanager.h>
+    #include <scrollingdialog.h>
+    #include <sdk_events.h>
+    #include <xtra_res.h>
+#endif
 
+#ifdef __WXMSW__
+    #include <winbase.h>
+#else
+    int GetShortPathName(const void*, void*, int){/* bogus */ return 0; };
+#endif
+
 #include <annoyingdialog.h>
 #include <backtracedlg.h>
 #include <breakpointsdlg.h>
+#include <cbstyledtextctrl.h>
 #include <disassemblydlg.h>
+#include <editarraystringdlg.h>
 #include <editbreakpointdlg.h>
 #include <examinememorydlg.h>
+#include <projectloader_hooks.h>
 #include <threadsdlg.h>
 #include <watchesdlg.h>
 
-#include "cbstyledtextctrl.h"
 #include "databreakpointdlg.h"
 #include "debuggerdriver.h"
-#include "debuggergdb.h"
 #include "debuggeroptionsdlg.h"
 #include "debuggeroptionsprjdlg.h"
 #include "editwatchesdlg.h"
 #include "editwatchdlg.h"
-#include "globals.h"
 
-#ifdef __WXMSW__
-    #include <winbase.h>
-#else
-    int GetShortPathName(const void*, void*, int){/* bogus */ return 0; };
-#endif
+#include "debuggergdb.h"
 
-#ifndef CB_PRECOMP
-    #include <wx/frame.h> // GetMenuBar
-    #include "cbproject.h"
-#endif
 
 #if defined(__APPLE__) && defined(__MACH__)
     #define LIBRARY_ENVVAR _T("DYLD_LIBRARY_PATH")
Index: src/plugins/debuggergdb/gdb_commands.h
===================================================================
--- src/plugins/debuggergdb/gdb_commands.h (revision 5883)
+++ src/plugins/debuggergdb/gdb_commands.h (working copy)
@@ -25,6 +25,7 @@
 #include <scriptingmanager.h>
 #include <sqplus.h>
 #include <infowindow.h>
+#include "logmanager.h"
 
 // FIXME (obfuscated#): remove this include
 #include "debuggertree.h"
Index: src/plugins/debuggergdb/debugger_defs.h
===================================================================
--- src/plugins/debuggergdb/debugger_defs.h (revision 5883)
+++ src/plugins/debuggergdb/debugger_defs.h (working copy)
@@ -11,6 +11,8 @@
 #include <vector>
 #include <tr1/memory>
 
+#include "debuggermanager.h"
+
 class DebuggerDriver;
 class DebuggerTree;
 
Index: src/src/main.h
===================================================================
--- src/src/main.h (revision 5883)
+++ src/src/main.h (working copy)
@@ -19,6 +19,7 @@
 #include "cbplugin.h"
 #include "sdk_events.h"
 #include "scripting/bindings/sc_base_types.h"
+#include "scrollingdialog.h"
 
 WX_DECLARE_HASH_MAP(int, wxString, wxIntegerHash, wxIntegerEqual, PluginIDsMap);
 WX_DECLARE_HASH_MAP(cbPlugin*, wxToolBar*, wxPointerHash, wxPointerEqual, PluginToolbarsMap);
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on October 28, 2009, 09:19:12 pm
I want to split the break-stop button in two different buttons - break and stop.
It is very annoying that when the user wants to stop the debugging he/she have to click the button twice.
This is not a problem. The real problem is that on the first click the cursor is move at the location the program was at the click.
This location can be totally different than the location the user is looking at.
For example while debugging codeblocks 99% of the time on the first click the app.cpp file is opened and I have to close it, which is very annoying.

Anyone against that change? I can make it configurable, of course?
And what icon should I use? Can I find the full icon set the CB is using?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on October 29, 2009, 01:57:13 am
For example while debugging codeblocks 99% of the time on the first click the app.cpp file is opened and I have to close it, which is very annoying.
Yes, it is annoying. But I have the difference experience, not the app.cpp opened. A file named "new_allocator" (as far I can remember, now, I have no C::B at hand) always opened. At this case, I still don't know where exactly my program halt. :(
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Pecan on October 29, 2009, 03:29:55 pm
For example while debugging codeblocks 99% of the time on the first click the app.cpp file is opened and I have to close it, which is very annoying.
Yes, it is annoying. But I have the difference experience, not the app.cpp opened. A file named "new_allocator" (as far I can remember, now, I have no C::B at hand) always opened. At this case, I still don't know where exactly my program halt. :(

Untick "Catch C++ exceptions" in debugger settings to avoid this problem.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on October 29, 2009, 04:00:14 pm
For example while debugging codeblocks 99% of the time on the first click the app.cpp file is opened and I have to close it, which is very annoying.
Yes, it is annoying. But I have the difference experience, not the app.cpp opened. A file named "new_allocator" (as far I can remember, now, I have no C::B at hand) always opened. At this case, I still don't know where exactly my program halt. :(

Untick "Catch C++ exceptions" in debugger settings to avoid this problem.


Thanks Pecan for your help, I will try it tomorrow in my lab's computer. :D
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: sbezgodov on November 05, 2009, 07:13:10 pm
Is it possible to use wxTreeListCtrl for watches window? I think its more suitable than wxPropertyGrid.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on November 05, 2009, 11:34:05 pm
Is it possible to use wxTreeListCtrl for watches window? I think its more suitable than wxPropertyGrid.
Why?
Patches are welcome, of course :)

p.s. I've tried to compile it, but it failed out of the box (linux 64bit), after some modification I've succeeded, but the sample crashed, when I've tried to start it!
Have you used it in a real multi platform project (different versions of windows doesn't count  :lol:)?

p.p.s. I've tried this  http://wxcode.sourceforge.net/components/treelistctrl/ "treelistctrl_2009-07-19.tar.gz   maintenance release"
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on December 07, 2009, 07:52:00 pm
The autotools build system seems broken in the debugger branch.
Can someone confirm this?

Here is the build log
Code
obfuscated@xlad ~/projects/codeblocks/brances/debugger_clean $ ./bootstrap 
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: You should add the contents of the following files to `aclocal.m4':
libtoolize:   `/usr/share/aclocal/libtool.m4'
libtoolize:   `/usr/share/aclocal/ltoptions.m4'
libtoolize:   `/usr/share/aclocal/ltversion.m4'
libtoolize:   `/usr/share/aclocal/ltsugar.m4'
libtoolize:   `/usr/share/aclocal/lt~obsolete.m4'
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
configure.in: installing `./install-sh'
configure.in: installing `./missing'
src/base/tinyxml/Makefile.am: installing `./depcomp'
src/plugins/contrib/Makefile.am:101: BUILD_CCCC does not appear in AM_CONDITIONAL
src/plugins/contrib/Makefile.am:105: BUILD_CPPCHECK does not appear in AM_CONDITIONAL
configure.in:7: installing `./config.guess'
configure.in:7: installing `./config.sub'


And after the ./bootstrap there is no configure script :(

System gentoo amd64 + gcc 4.4.2/glibc 2.9
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on December 07, 2009, 08:45:49 pm
The autotools build system seems broken in the debugger branch.
Can someone confirm this?

Should be fixed in svn r5957.
Can you please test it ?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on December 07, 2009, 08:54:16 pm
It is fixed.
But your patch for the notebook problems breaks the BrowseTracker plugin

Code
/wxscintilla/include -Ulinux -Uunix -g -DDEBUG -DCB_AUTOCONF -march=core2 -O2 -fweb -frename-registers -pipe -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -c Version.cpp  -fPIC -DPIC -o .libs/Version.o
BrowseTracker.cpp: In member function ‘bool BrowseTracker::IsEditorBaseOpen(EditorBase*)’:
BrowseTracker.cpp:2777: error: cannot convert ‘cbAuiNotebook*’ to ‘wxAuiNotebook*’ in initialization
make[4]: *** [BrowseTracker.lo] Error 1
make[4]: *** Waiting for unfinished jobs....
make[4]: Leaving directory `/var/tmp/portage/dev-util/codeblocks-9999-r20/work/codeblocks-9999/src/plugins/contrib/BrowseTracker'
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on December 07, 2009, 09:03:36 pm
It is fixed.
But your patch for the notebook problems breaks the BrowseTracker plugin

Code
/wxscintilla/include -Ulinux -Uunix -g -DDEBUG -DCB_AUTOCONF -march=core2 -O2 -fweb -frename-registers -pipe -DCB_PRECOMP -Winvalid-pch -fPIC -DPIC -fexceptions -c Version.cpp  -fPIC -DPIC -o .libs/Version.o
BrowseTracker.cpp: In member function ‘bool BrowseTracker::IsEditorBaseOpen(EditorBase*)’:
BrowseTracker.cpp:2777: error: cannot convert ‘cbAuiNotebook*’ to ‘wxAuiNotebook*’ in initialization
make[4]: *** [BrowseTracker.lo] Error 1
make[4]: *** Waiting for unfinished jobs....
make[4]: Leaving directory `/var/tmp/portage/dev-util/codeblocks-9999-r20/work/codeblocks-9999/src/plugins/contrib/BrowseTracker'

Yes and no, the patch needs to be updated, because BrowseTracker has changes.

As fix, you can change wxAuiNotebook in line 2777 to cbAuiNotebook and the include in line 94 to "cbauibook.h".
No time to create a new patch at the moment, maybe later this evening or tomorrow.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on December 08, 2009, 01:29:51 am
Patch for cppcheck in the debugger branch

Code
Index: src/plugins/contrib/CppCheck/CppCheck-unix.cbp
===================================================================
--- src/plugins/contrib/CppCheck/CppCheck-unix.cbp      (revision 5956)
+++ src/plugins/contrib/CppCheck/CppCheck-unix.cbp      (working copy)
@@ -32,7 +32,7 @@
                        <Add option="-DCB_PRECOMP" />
                        <Add option="-DcbDEBUG" />
                        <Add directory="../../../include" />
-                       <Add directory="../../../include/wxscintilla/include" />
+                       <Add directory="../../../sdk/wxscintilla/include" />
                </Compiler>
                <Linker>
                        <Add option="`wx-config --libs`" />


The same fix seems to be needed in the autotools system.
Also does ./configure --with-contrib-plugins="all,-CppCheck" should work (build all plugins except the CppCheck)?
My test doesn't seem to work :(
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on December 08, 2009, 06:48:12 am
I saw yesterday night.
I will fix this today.
It happens because (wx)scintilla was moved to another folder.
Might be the same in the scintilla-branch.
I will test (and fix if needed) this also.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on December 08, 2009, 06:55:04 am
The same fix seems to be needed in the autotools system.
Also does ./configure --with-contrib-plugins="all,-CppCheck" should work (build all plugins except the CppCheck)?
My test doesn't seem to work :(
That is correct. I've just not checked out the files that need to be modified. ;-)
All you'll need to do is to compare the files "acinclude.m4" and "configure.in" with the one from the branch. and "copy" the missing changes. I'll do it later when I've time. ("codeblocks.spec.in" is another file you
ll need to take care of if you want to create a dist package.)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on December 08, 2009, 06:55:34 am
I will test (and fix if needed) this also.
Done it already while you were typing... ;-) "At your fingertips..."  :lol: :lol: :lol:
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on December 08, 2009, 09:09:07 am
Build is OK now, thanks.

Here is the updated patch for the auinotebook: http://smrt.is-a-geek.org/codeblocks/cb_aui_notebook.patch (http://smrt.is-a-geek.org/codeblocks/cb_aui_notebook.patch)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on December 12, 2009, 12:21:19 am
Next patch for the branch: http://smrt.is-a-geek.org/codeblocks/dbg_refactor0007.patch

What it does:
1. Adds callbacks for expanding/collapsing watches.
2. Adds callback to test if the ToolMenu should be enabled
3. Extracts the two methods for switching the layout to the base class
4. Adds ShowBacktraceDialog in DebuggerManager
5. cbDebuggerPlugin::BuildModuleMenu does something only for the active debugger plugin
6. Fix a bug with the expanded status of a watch (don't remember the details any more)

Hope it is good and can be applied. Comments are welcome.

And now here is the link for my plugin: svn://smrt.is-a-geek.org/cb_gdb_mi/debugger_gdbmi
0. This is a GDB/mi debugger plugin.
1. Requires GDB 7.0+ and CB with the patch in this post applied
2. It works only on linux (for the moment) :( .
3. It does the basic stuff at the moment.
4. It supports the new python pretty printers (gdb has some problems though :( )

So please test. I'm sure it has many problems which I hope I can fix.

p.s. I hope I'll have the time to port it windows tomorrow
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on December 14, 2009, 03:19:10 pm
Next patch for the branch: http://smrt.is-a-geek.org/codeblocks/dbg_refactor0007.patch
Testing... :-)

And now here is the link for my plugin: svn://smrt.is-a-geek.org/cb_gdb_mi/debugger_gdbmi
I am unable to access this repo. :-( Is it possible to access this via http, too / providing a patch?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on December 14, 2009, 04:36:23 pm
I am unable to access this repo. :-( Is it possible to access this via http, too / providing a patch?
No, I've to set it up. What is the problem with the native svn protocol? (I've not tested it from the outside world :( )
The plugin is 99% unrelated to the current c::b debugger plugin, so I can't provide a patch.
I can provide an archive with the code.

I've made the plugin to almost work on win32, tonight will try to fix it 100%.
One thing I've noticed is that the win32 gdb has no python support => no pretty printers on win32 :(
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on December 14, 2009, 08:13:47 pm
Morten, can you try this patch http://smrt.is-a-geek.org/codeblocks/dbg_refactor0008.patch too?
It is possible that you can't apply it automatically.

The patch fixes a problem I've with the gdb/mi plugin and path like: "C:\\dev\projects\\bla\bla.cpp"
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on December 15, 2009, 04:17:30 pm
One thing I've noticed is that the win32 gdb has no python support => no pretty printers on win32 :(
so bad to hear. is it possible that someone build a win32 gdb that support python? :D
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on December 15, 2009, 10:59:38 pm
Here is the correct link to my svn: svn://smrt.is-a-geek.org/cb_gdb_mi/debbugger_gdbmi
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on December 16, 2009, 06:34:56 am
Here is the correct link to my svn: svn://smrt.is-a-geek.org/cb_gdb_mi/debbugger_gdbmi
Yupp - this one works. :-)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on December 17, 2009, 12:19:19 am
Code
 	* debugger branch: update to wxpropgrid hopefully fixing the visualisation issue with +/- on Windows
Bug is fixed, Thanks Morten.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 02, 2010, 05:23:42 pm
Next patch for the branch: http://smrt.is-a-geek.org/codeblocks/dbg_refactor0007.patch
Testing... :-)

Any progress?
I have lots of changes coming, but want to see this patch applied :) and sorry if I'm rushing you.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 03, 2010, 03:11:40 pm
Any progress?
It's applied and ready for commit at work. As I didn't work during x-mas there is a slight delay... ;-) Gimme some time to be back at work (tomorrow to be precise).
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 03, 2010, 04:11:57 pm
You work on C::B at work  8) :lol:

I wasn't at work too during Christmas, so I have plenty of time to work on C::B  :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 03, 2010, 06:00:10 pm
You work on C::B at work  8) :lol:
I don't, I just apply patches there. Hence I am using it for development at work certainly. Thus a good patch level is very helpful.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 04, 2010, 08:34:50 am
...try again. I avoided another merge with trunk on purpose as thee seems to be difficulties atm...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 04, 2010, 11:43:47 pm
Done... and here is the next patch:

http://smrt.is-a-geek.org/codeblocks/dbg_refactor0008.patch

What is done:
1. Moved more methods to the base class - related to the project compilation and running the console on *nix
2. From now on there will be only one debugger toolbar.
3. Split Break and Stop buttons on the toolbar - need an icon for the break button
4. Watch improvements:
4.1. Added a Type column.
4.2. Now the user add watches by dragging string onto the watch window
5. Ensure the active thread is visible in the thread dialog
6. When the last debugger plugin is unloaded close all the debugger windows
7. Reimplemented the feature that allows the user to add breakpoints while the debuggee is running
8. Remember the last active debugger

I've introduce some bug related to the attaching to processes, which I've marked with FIXMEs and I hope I'll fix them soon.

PLEASE TEST, because I'm sure no one is running the debugger branch actively (or is shy to report problems). The branch before this was crashing annoyingly and badly when adding and removing breakpoints while the debuggee was running.

Also any feedback on the gdb/mi plugin is quite welcome.

Best regards....
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 05, 2010, 07:09:00 am
http://smrt.is-a-geek.org/codeblocks/dbg_refactor0008.patch
Hey - we were already there, see here:
http://forums.codeblocks.org/index.php/topic,10908.msg79425.html#msg79425

I'll rename it to 0009... ;-)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 05, 2010, 07:09:52 am
The branch before this was crashing annoyingly and badly when adding and removing breakpoints while the debuggee was running.
I knew but as it was easy to fix I though you had handled that already...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 05, 2010, 08:45:01 am
http://smrt.is-a-geek.org/codeblocks/dbg_refactor0008.patch
Hmmm... with this patch applied I cannot debug C::B anymore.
I am placing a BP in "MainFrame* CodeBlocksApp::InitFrame()" (src/app.cpp) and hit "debug".
this is what I see in the debug log:
> break "C:/Devel/CodeBlocks/src/src/app.cpp:401"
Breakpoint 1 at 0x4026ab: file C:\Devel\CodeBlocks\src\src\app.cpp, line 401.
>>>>>>cb_gdb:
> run
pid=3060 tid=5908 code=LOAD_DLL_DEBUG_EVENT)
gdb: Loading dll "C:\WINDOWS\system32\ws2help.dll" at 0x71a00000.
ContinueDebugEvent (cpid=3060, ctid=5908, DBG_CONTINUE);
gdb: kernel event for pid=3060 tid=5908 code=LOAD_DLL_DEBUG_EVENT)
gdb: Loading dll "C:\Devel\CodeBlocks\src\devel\codeblocks.dll" at 0xb10000.
ContinueDebugEvent (cpid=3060, ctid=5908, DBG_CONTINUE);
gdb: kernel event for pid=3060 tid=5908 code=LOAD_DLL_DEBUG_EVENT)
gdb: Loading dll "C:\Devel\CodeBlocks\src\devel\wxpropgrid.dll" at 0x6e440000.
ContinueDebugEvent (cpid=3060, ctid=5908, DBG_CONTINUE);
gdb: kernel event for pid=3060 tid=5908 code=LOAD_DLL_DEBUG_EVENT)
gdb: Loading dll "C:\Devel\CodeBlocks\src\devel\wxscintilla.dll" at 0x6c980000.
ContinueDebugEvent (cpid=3060, ctid=5908, DBG_CONTINUE);
gdb: kernel event for pid=3060 tid=5908 code=EXCEPTION_DEBUG_EVENT)

Then nothing happens and I can only stop the debugger (only "break" and "stop" is available, but "break" does nothing).

when I hit "stop" this is in the debug log:
Exception condition detected on fd 0
error detected on stdin
ContinueDebugEvent (cpid=3060, ctid=5908, DBG_CONTINUE);
ContinueDebugEvent (cpid=3060, ctid=4612, DBG_CONTINUE);
ContinueDebugEvent (cpid=3060, ctid=5908, DBG_CONTINUE);
ContinueDebugEvent (cpid=3060, ctid=4612, DBG_CONTINUE);
gdb: windows_close, inferior_ptid=3060

Any hints???
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 05, 2010, 09:44:03 am
Nargh... just forget about this. I still had the patch of yours applied concerning PipedProcess. This has bitten me literally the first time now. I've removed this for now and forever and suddenly all works again (including debugging wx apps). It shows that this patch is not working reliable and we'd better not apply it.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 19, 2010, 10:37:20 am
Can someone sync the debugger branch with trunk?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 19, 2010, 02:04:03 pm
Can someone sync the debugger branch with trunk?
Should be me then... right? Be a little patient...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 19, 2010, 08:07:21 pm
Seems the auto-fu is broken...
Code
libtoolize: putting auxiliary files in `.'.
libtoolize: copying file `./ltmain.sh'
libtoolize: You should add the contents of the following files to `aclocal.m4':
libtoolize:   `/usr/share/aclocal/libtool.m4'
libtoolize:   `/usr/share/aclocal/ltoptions.m4'
libtoolize:   `/usr/share/aclocal/ltversion.m4'
libtoolize:   `/usr/share/aclocal/ltsugar.m4'
libtoolize:   `/usr/share/aclocal/lt~obsolete.m4'
libtoolize: Consider adding `AC_CONFIG_MACRO_DIR([m4])' to configure.in and
libtoolize: rerunning libtoolize, to keep the correct libtool macros in-tree.
libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am.
configure.in: installing `./install-sh'
configure.in: installing `./missing'
src/base/tinyxml/Makefile.am: installing `./depcomp'
configure.in:7: installing `./config.guess'
configure.in:7: installing `./config.sub'
configure.in:209: required file `src/plugins/scriptedwizard/resources/sharedlib/files/Makefile.in' not found


Also you have not fully applied the previous patch... here is what's left: http://smrt.is-a-geek.org/codeblocks/dbg_refactor0010.patch
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 19, 2010, 08:27:34 pm
Seems the auto-fu is broken...
Nope... I know why. :-/

Seems I have to finally change my branches checkouts and scripts... :-(
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 19, 2010, 09:10:42 pm
Seems I have to finally change my branches checkouts and scripts... :-(
...try again...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 19, 2010, 10:27:24 pm
Both are fixed, thanks
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 21, 2010, 09:57:11 am
Morten: Does the new break button work for you on windows?
Here it is broken with wx apps :(
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 14, 2010, 09:33:26 pm
Morten can you update the wxPropGrid, to latest svn revision, if you have no time you can give me the steps to update it in my local copy?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 16, 2010, 12:10:50 am
Thank you Morten....

But the build using the autofu system seems to be broken:
Code
.libs/cbexception.o: In function `cbException':
/usr/include/wx-2.8/wx/thread.h:554: multiple definition of `cbException::cbException(wxString const&, wxString const&, int)'
.libs/cbexception.o:/usr/include/wx-2.8/wx/thread.h:554: first defined here
.libs/cbexception.o: In function `cbException':
/var/tmp/portage/dev-util/codeblocks-9999-r20/work/codeblocks-9999/src/sdk/cbexception.cpp:24: multiple definition of `cbException::cbException(wxString const&, wxString const&, int)'
.libs/cbexception.o:/var/tmp/portage/dev-util/codeblocks-9999-r20/work/codeblocks-9999/src/sdk/cbexception.cpp:24: first defined here
.libs/cbexception.o: In function `cbException::ShowErrorMessage(bool)':
/var/tmp/portage/dev-util/codeblocks-9999-r20/work/codeblocks-9999/src/sdk/cbexception.cpp:32: multiple definition of `cbException::ShowErrorMessage(bool)'
.libs/cbexception.o:/var/tmp/portage/dev-util/codeblocks-9999-r20/work/codeblocks-9999/src/sdk/cbexception.cpp:32: first defined here
.libs/cbexception.o: In function `~cbException':
/var/tmp/portage/dev-util/codeblocks-9999-r20/work/codeblocks-9999/src/sdk/cbexception.cpp:27: multiple definition of `cbException::~cbException()'
.libs/cbexception.o:/var/tmp/portage/dev-util/codeblocks-9999-r20/work/codeblocks-9999/src/sdk/cbexception.cpp:27: first defined here
.libs/cbexception.o: In function `~cbException':
/var/tmp/portage/dev-util/codeblocks-9999-r20/work/codeblocks-9999/src/sdk/cbexception.cpp:27: multiple definition of `cbException::~cbException()'
.libs/cbexception.o:/var/tmp/portage/dev-util/codeblocks-9999-r20/work/codeblocks-9999/src/sdk/cbexception.cpp:27: first defined here
.libs/cbexception.o: In function `~cbException':
/var/tmp/portage/dev-util/codeblocks-9999-r20/work/codeblocks-9999/src/sdk/cbexception.cpp:27: multiple definition of `cbException::~cbException()'
.libs/cbexception.o:/var/tmp/portage/dev-util/codeblocks-9999-r20/work/codeblocks-9999/src/sdk/cbexception.cpp:27: first defined here
.libs/editor_hooks.o: In function `EditorHooks::HasRegisteredHooks()':
/usr/include/wx-2.8/wx/thread.h:554: multiple definition of `EditorHooks::HasRegisteredHooks()'
.libs/editor_hooks.o:/usr/include/wx-2.8/wx/thread.h:554: first defined here
.libs/editor_hooks.o: In function `EditorHooks::CallHooks(cbEditor*, wxScintillaEvent&)':
/var/tmp/portage/dev-util/codeblocks-9999-r20/work/codeblocks-9999/src/sdk/editor_hooks.cpp:55: multiple definition of `EditorHooks::CallHooks(cbEditor*, wxScintillaEvent&)'
.libs/editor_hooks.o:/var/tmp/portage/dev-util/codeblocks-9999-r20/work/codeblocks-9999/src/sdk/editor_hooks.cpp:55: first defined here
.libs/editor_hooks.o: In function `EditorHooks::UnregisterHook(int, bool)':
/var/tmp/portage/dev-util/codeblocks-9999-r20/work/codeblocks-9999/src/sdk/editor_hooks.cpp:33: multiple definition of `EditorHooks::UnregisterHook(int, bool)'
.libs/editor_hooks.o:/var/tmp/portage/dev-util/codeblocks-9999-r20/work/codeblocks-9999/src/sdk/editor_hooks.cpp:33: first defined here
.libs/editor_hooks.o: In function `EditorHooks::RegisterHook(EditorHooks::HookFunctorBase*)':
/var/tmp/portage/dev-util/codeblocks-9999-r20/work/codeblocks-9999/src/sdk/editor_hooks.cpp:22: multiple definition of `EditorHooks::RegisterHook(EditorHooks::HookFunctorBase*)'
.libs/editor_hooks.o:/var/tmp/portage/dev-util/codeblocks-9999-r20/work/codeblocks-9999/src/sdk/editor_hooks.cpp:22: first defined here
.libs/nullptr.o:(.bss+0x0): multiple definition of `nullptr'
.libs/nullptr.o:(.bss+0x0): first defined here
collect2: ld returned 1 exit status
make[3]: *** [libcodeblocks.la] Error 1
make[3]: Leaving directory `/var/tmp/portage/dev-util/codeblocks-9999-r20/work/codeblocks-9999/src/sdk'
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory `/var/tmp/portage/dev-util/codeblocks-9999-r20/work/codeblocks-9999/src/sdk'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory `/var/tmp/portage/dev-util/codeblocks-9999-r20/work/codeblocks-9999/src'

Building from C::B seems to work

HEHE: post 555, go go subaru rally team from the 90's
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on February 16, 2010, 06:29:12 am
But the build using the autofu system seems to be broken:
Weired. But I would need to see the full log to clarify. I can try myself but in a VM it takes ages for the automake to complete, so I usually don't and leave that to somebody using Linux natively.

BTW (just saw that I mssed that somehow... :oops:):
Morten: Does the new break button work for you on windows?
Not sure what you mean with "new" (I see the buttons as they have always been), but yes, "break" works, even in wx apps.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 16, 2010, 08:29:44 am
Weired. But I would need to see the full log to clarify. I can try myself but in a VM it takes ages for the automake to complete, so I usually don't and leave that to somebody using Linux natively.
Here it is http://smrt.is-a-geek.org/codeblocks/build.log (probably I need to rerun it with -j1) - I've run it with -j1 and it does break, with the same error

Not sure what you mean with "new" (I see the buttons as they have always been), but yes, "break" works, even in wx apps.
There are two buttons now, one that breaks the app and one that stops the app. I've seen the break button doing nothing when clicked (now I can reproduce it :( ).

Another thing I've seen and I can reproduce at the moment is that a deleted breakpoint is hit again and again, even there is not red marker. Have you seen this, too?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 16, 2010, 08:55:21 pm
Another thing I've seen and I can reproduce at the moment is that a deleted breakpoint is hit again and again, even there is not red marker. Have you seen this, too?

The text in bold should be can't :(

Can I ask for another update of the wxPropertiGrid  :lol: 8)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on February 17, 2010, 06:45:47 am
Can I ask for another update of the wxPropertiGrid  :lol: 8)
Huh? I just did update it! :shock: Do you really mean again? (Which wxPropGrid SVN revision you are targeting?!).
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 17, 2010, 08:07:53 am
Yes, another one, I'm communicating with Jaakko Salli (wxPG creator/maintainer) and he added one feature and now has fixed one bug + another new feature :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on February 17, 2010, 09:23:41 am
Yes, another one, I'm communicating with Jaakko Salli (wxPG creator/maintainer) and he added one feature and now has fixed one bug + another new feature :)
Ok... I'll do.

BTW: Do you have this strange bug, too where the first column of the propgrid sometimes is very small in wxSmith?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 17, 2010, 12:21:39 pm
Thanks.

No, I don't have it in my latest patchset (no posted here, but will when I have more to show).
But I was having it before the latest changes in the wxPropertyGrid.
The way to fix it:
Code
m_grid->SetColumnProportions(0, 50);
m_grid->SetColumnProportions(1, 50);

// I may have misspelled the method name!
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 19, 2010, 01:17:53 am
Here is another patch for the branch... some GUI improvements

1. Delete key in Breakpoints window deletes the selected breakpoint
2. Fixed the splitter position in the watches window (thanks to Jaakko Salli)
3. Added calls to wxPropertyGrid::Refresh here and there in order to fix, some rendering bugs
4. Fixed the changed value handling in the watches window
5. Ensure visible the selected/active frame in the backtrace window
6. Some cleaning here and there

And the patch : http://smrt.is-a-geek.org/codeblocks/dbg_refactor0011.1.patch

Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 28, 2010, 05:29:31 pm
Morten can you apply the last patch, any problems with it?

Also I've noticed a strange bug ->
1. Select something in the editor
2. Start to drag it
3. Drop it in the watches window
4. The text is cut not copied

I think this is caused by some change in the wxScintilla, but I may be wrong...
Can someone familiar with wxScintilla's code tell me what is wrong/fix the bug?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on February 28, 2010, 06:08:02 pm
Also I've noticed a strange bug ->
1. Select something in the editor
2. Start to drag it
3. Drop it in the watches window
4. The text is cut not copied

I think this is caused by some change in the wxScintilla, but I may be wrong...
Can someone familiar with wxScintilla's code tell me what is wrong/fix the bug?

Might be related to a fix I apllied to our wxScintilla source (related to changes in newer scintilla) to fix a bug in drag and drop, where dragged text was always copied and never moved.
I will look into it.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on February 28, 2010, 06:25:18 pm
Also I've noticed a strange bug ->
1. Select something in the editor
2. Start to drag it
3. Drop it in the watches window
4. The text is cut not copied

I think this is caused by some change in the wxScintilla, but I may be wrong...
Can someone familiar with wxScintilla's code tell me what is wrong/fix the bug?

Might be related to a fix I apllied to our wxScintilla source (related to changes in newer scintilla) to fix a bug in drag and drop, where dragged text was always copied and never moved.
I will look into it.

Works fine here (actual sources from debugger-branch).
Is it possible, that it is related to your latest (not yet comitted) patch ?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on February 28, 2010, 09:28:48 pm
Works fine here (actual sources from debugger-branch).
Is it possible, that it is related to your latest (not yet comitted) patch ?

I just tested on windows, and indeed it moves the selected word.
As written before I will look into it.

I will be without internet the next week (or I have to crack the wlan of the hotel I will be), so don't worry if you do not here anything before next weekend.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 28, 2010, 11:02:23 pm
OK, Thank you for your efforts.

Just for clarification: My working codeblocks does not have the patch applied, also I've implemented a DropTarget, which doesn't have control over this kind of behaviour.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on February 28, 2010, 11:31:04 pm
OK, Thank you for your efforts.

Just for clarification: My working codeblocks does not have the patch applied, also I've implemented a DropTarget, which doesn't have control over this kind of behaviour.

It has, the fix for this issue is quite simple: the droptarget returns false and therefore vetos the operation.
Works fine on my virtual-vista and does not change behaviour on linux.

Fix committed as svn r6185.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on March 01, 2010, 01:42:52 am
Jens: the fix does not work :(

Do you know where I can find the code for the drop target of the edit/text control?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on March 01, 2010, 07:41:47 am
BTW: Whatever you did
with your repo for the debugger plugin it makes the repo inaccessible. I always receive the error:

Mismatched FS module version for 'fsfs': Found 1.6.6 expected 1.6.9.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on March 01, 2010, 08:52:47 am
Hi, all debugger exports, did you consider saving the breakpoint after we close a project. and load the breakpoint when loading a project?

I have done that several months ago, I nearly forget that. see here: Watches and breakpoints persistent (http://developer.berlios.de/patch/?func=detailpatch&patch_id=2775&group_id=5358), I'm not sure this can be easily done in the debugger branch. :D

Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on March 01, 2010, 09:21:48 am
Morten: I've updated the svn server, probably I need to do something with the repo, will look at it tonight

Olly: I've not forgotten this feature, but I don't like the implementation! C::B needs an API to store user information per project/workspace in single file, not N files as it is now.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on March 01, 2010, 09:43:06 am
see here: Watches and breakpoints persistent (http://developer.berlios.de/patch/?func=detailpatch&patch_id=2775&group_id=5358), I'm not sure this can be easily done in the debugger branch. :D
I still have that merged (as far as possible) with the debugger branch in my local copy. It's not forgotten, just pending as it needs some re-write.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on March 03, 2010, 01:50:43 am
Mismatched FS module version for 'fsfs': Found 1.6.6 expected 1.6.9.

My svn server needed a restart after the update, should work now  8)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on March 03, 2010, 07:37:55 am
should work now  8)
Yes, it's back again.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on March 03, 2010, 05:36:44 pm
And another patch: http://smrt.is-a-geek.org/codeblocks/dbg_refactor0012.patch

1. Implemented Set Next statement/Jump to cursor, yey
2. Fixed a bug in the code for adding breakpoints
3. Made the watches window more user friendly
4. Fixed a redraw issue in watches window

Morten: Do you have a pause icon in the same style as the other icons in the debugger set?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Ceniza on March 03, 2010, 07:29:18 pm
1. Implemented Set Next statement/Jump to cursor, yey

That sounds really nice :D
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: blueshake on March 04, 2010, 04:08:18 am
hope it can be merged into trunk as soon as possible. :D :D :D
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on March 04, 2010, 09:28:20 am
You're welcome to test it  :lol:  :P
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on March 06, 2010, 09:23:54 pm
Little addition to the previous patch: http://smrt.is-a-geek.org/codeblocks/dbg_refactor0012.1.patch

1. Implemented Set Next statement/Jump to cursor, yey
2. Fixed a bug in the code for adding breakpoints
3. Made the watches window more user friendly
4. Fixed a redraw issue in watches window
New: 5.  Fixed bug: "adding breakpoint while running doesn't hide the current position marker"
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on March 08, 2010, 02:54:01 pm
Morten: Do you have a pause icon in the same style as the other icons in the debugger set?
No, but I think it should be orange and have the typical pause sign as you know it from CD players, like:

[ " ]

:lol:
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on March 08, 2010, 04:03:18 pm
Agreed  :lol: now we need someone to do it :)
Where have you got the other icons in the new set?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on March 08, 2010, 04:19:59 pm
Where have you got the other icons in the new set?
I've forgotten. It was either from a patch (search for closed patches assigned to me in the patch tracker) or (even worse) from the forums. But I think we should start with re-colouring the existing icon from green to orange... this can be easily done.- ;-)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on March 08, 2010, 04:24:41 pm
OK, I'll see what I can do.

Another question:
What do you think is needed in order to get this branch merged in trunk?
The major feature that is missing (user visible) is "local variables/function arguments", but for that one I'll need to modify C::B a lot, because I want them to be in separate windows, not as before in the watches window.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on March 11, 2010, 11:19:46 pm
OK, I have an icon:

22x22: http://smrt.is-a-geek.org/codeblocks/new_icon/dbgpause.png
16x16: http://smrt.is-a-geek.org/codeblocks/new_icon/16x16/dbgpause.png
patch: http://smrt.is-a-geek.org/codeblocks/new_icon/new_icon.patch

p.s. the icons look very bad with a darker theme.

http://smrt.is-a-geek.org/codeblocks/new_icon/icon_bug.png // notice the halos on the Run, Build And Run and Start/Continue icons

Would you accept a fix for them ?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on March 15, 2010, 11:02:43 am
Morten: Can you update wxPropGrid?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on March 15, 2010, 08:34:15 pm
Morten: Can you update wxPropGrid?
I can't atm... I am not on a PC with C::B for some time (not too long... no worries...). but I keep it in mind.
BTW: The icon looks very good! :-)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: sbezgodov on March 18, 2010, 02:05:17 pm
p.s. the icons look very bad with a darker theme.

This arises from lacking alpha channel in png icons. I don't know if it possible to convert all images automatically with gimp or any other software.

If you want to add additional button to pause debugger, it will be better if Start, Continue and Pause commands can be executed by identical keyboard combination and toolbar button. It is very useful, i think. There is wxToolbar::SetToolNormalBitmap method to change button icon, but i'm not clear about disabled icon.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on March 18, 2010, 02:14:03 pm
This arises from lacking alpha channel in png icons. I don't know if it possible to convert all images automatically with gimp or any other software.
There is no automatic way to fix them and they have alpha channel, but aren't cropped carefully.

If you want to add additional button to pause debugger, it will be better if Start, Continue and Pause commands can be executed by identical keyboard combination and toolbar button. It is very useful, i think. There is wxToolbar::SetToolNormalBitmap method to change button icon, but i'm not clear about disabled icon.
No sure what you're talking about, can you explain better?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on March 18, 2010, 04:32:23 pm
Morten: Can you update wxPropGrid?
but I keep it in mind.
I did now. :-)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on March 18, 2010, 05:58:49 pm
Thanks, I'll test as I get home.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: sbezgodov on March 18, 2010, 07:48:16 pm
No sure what you're talking about, can you explain better?

Debugger has commands. Would be great if Start and Continue commands has same keyboard key, e.g. F5 and menu entry.
Example: I start debugging by pressing F5 (now F8). My program reaches breakpoint. Then again press F5 (now Ctrl-F7) and my program continues.
Keybinder plugin doesn't allow to bind two commands to one key.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on March 26, 2010, 12:31:12 pm
Morten: Can you do another wxPropGrid update?  :lol: 8)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on March 26, 2010, 08:46:38 pm
Morten: Can you do another wxPropGrid update?  :lol: 8)
What about setting up an automatic email that reminds me every week or so?! :lol:

Seriously: It'll need some time, I am without an up-to-date C::B at the moment... so it'll have to wait until Monday, most likely.

Let me take the answer to tell you that the new framework still works just fine for me. I was debugging quite a lot recently (including th new "pause" button ;-)). No issues so far.... anything I should try explicitly next time?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on April 06, 2010, 09:17:26 am
uf, I've missed this last post :(

There were some linux specific bugs in wxPropGrid.

What you should look for:
1. Rendering/refreshing bugs in the watches window when:
* opening/closing a watch
* deleting watch with the context menu and keyboard (delete key)
* renaming a watch with the context menu and keyboard (insert key)
2. Does highlighting the changes when stepping through the code works correctly.

I'll post a patch that has some small fixes in the watches window...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on April 06, 2010, 09:39:08 pm
Here is the next patch: http://smrt.is-a-geek.org/codeblocks/dbg_refactor0013.patch

1. Run host it terminal
2. Disable the debugger tooltip, when the users starts a drag in the editor (change wxScintilla)
3. Fixed the style in the watchesdlg.cpp, fixed a bug when deleting a watch (can't remember exactly what)
4. Close the console when the user unloads the project/closes C::B, while the debugger is running

Please give me some feadback on 1., because I've changed parts of C::B that I'm not very familiar with...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on April 14, 2010, 06:21:37 pm
Have:
windows xp sp2
codeblocks 8.02
codeblocks trunk svn R6203 (built with codeblocks 8.02)
wxwidgets from wxpack distribution

svn branch wxpropgrid_debugger  (fetched today 2010/04/14)

attempted to build branch with local trunk built version (figured a good test), and the files reported
as missing  [edit: for contribplugins.workspace] do seem to absent from the sub-directory locations referenced, although a number of them seem to appear in the wxsmith/wxwidgets sub-directories... [edit: somehow I mis-looked - the files _do_ seem to be present, so...]

***Have I done something wrong or is the branch currently incorrect/incomplete? [Are switches for include specs somehow missing

(I just tried to skim through all pages of thread, but didn't spot anything else I thought was needed.)

last part of build messages output:
||=== wxSmith - Aui, Windows ===|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiPaneInfoProperty.h|22|error: properties/wxsproperties.h: No such file or directory|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiManager.h|24|error: wxwidgets/wxsparent.h: No such file or directory|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiManager.h|25|error: wxwidgets/wxsflags.h: No such file or directory|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\..\wxAuiToolBar\wxsAuiToolBar.h|22|error: wxwidgets/wxscontainer.h: No such file or directory|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiManagerParentQP.h|35|error: wxsadvqppchild.h: No such file or directory|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiManager.cpp|22|error: wxwidgets/wxsitemresdata.h: No such file or directory|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiPaneInfoProperty.h|31|error: expected class-name before '{' token|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiPaneInfoProperty.h|58|error: 'wxsPropertyContainer' has not been declared|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiPaneInfoProperty.h|58|error: 'wxPropertyGridManager' has not been declared|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiPaneInfoProperty.h|58|error: 'wxPGId' has not been declared|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiPaneInfoProperty.h|59|error: 'wxsPropertyContainer' has not been declared|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiPaneInfoProperty.h|59|error: 'wxPropertyGridManager' has not been declared|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiPaneInfoProperty.h|59|error: 'wxPGId' has not been declared|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiPaneInfoProperty.h|60|error: 'wxsPropertyContainer' has not been declared|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiPaneInfoProperty.h|60|error: 'wxPropertyGridManager' has not been declared|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiPaneInfoProperty.h|60|error: 'wxPGId' has not been declared|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiPaneInfoProperty.h|61|error: 'wxsPropertyContainer' has not been declared|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiPaneInfoProperty.h|61|error: 'TiXmlElement' has not been declared|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiPaneInfoProperty.h|62|error: 'wxsPropertyContainer' has not been declared|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiPaneInfoProperty.h|62|error: 'TiXmlElement' has not been declared|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiPaneInfoProperty.h|63|error: 'wxsPropertyContainer' has not been declared|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiPaneInfoProperty.h|63|error: 'wxsPropertyStream' has not been declared|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiPaneInfoProperty.h|64|error: 'wxsPropertyContainer' has not been declared|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiPaneInfoProperty.h|64|error: 'wxsPropertyStream' has not been declared|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiPaneInfoProperty.h|89|error: expected class-name before '{' token|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiPaneInfoProperty.h|105|error: 'wxsPropertyContainer' has not been declared|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiPaneInfoProperty.h|105|error: 'TiXmlElement' has not been declared|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiPaneInfoProperty.h|106|error: 'wxsPropertyContainer' has not been declared|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiPaneInfoProperty.h|106|error: 'TiXmlElement' has not been declared|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiPaneInfoProperty.h|107|error: 'wxsPropertyContainer' has not been declared|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiPaneInfoProperty.h|107|error: 'wxsPropertyStream' has not been declared|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiPaneInfoProperty.h|108|error: 'wxsPropertyContainer' has not been declared|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiPaneInfoProperty.h|108|error: 'wxsPropertyStream' has not been declared|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\..\wxAuiToolBar\wxsAuiToolBar.h|26|error: expected class-name before '{' token|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\..\wxAuiToolBar\wxsAuiToolBar.h|30|error: expected ')' before '*' token|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\..\wxAuiToolBar\wxsAuiToolBar.h|36|error: 'wxsItem' has not been declared|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\..\wxAuiToolBar\wxsAuiToolBar.h|37|error: 'wxsParent' has not been declared|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\..\wxAuiToolBar\wxsAuiToolBar.h|38|error: ISO C++ forbids declaration of 'wxsPropertyContainer' with no type|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\..\wxAuiToolBar\wxsAuiToolBar.h|38|error: 'wxsPropertyContainer' declared as a 'virtual' field|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\..\wxAuiToolBar\wxsAuiToolBar.h|38|error: expected ';' before '*' token|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\..\wxAuiToolBar\wxsAuiToolBar.h|43|error: 'wxsItem' has not been declared|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\..\wxAuiToolBar\wxsAuiToolBar.h|44|error: 'wxsItem' has not been declared|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\..\wxAuiToolBar\wxsAuiToolBar.h|48|error: ISO C++ forbids declaration of 'wxsItem' with no type|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\..\wxAuiToolBar\wxsAuiToolBar.h|48|error: expected ';' before '*' token|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiManager.h|29|error: 'wxsFlags' is not a namespace-name|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiManager.h|29|error: expected namespace-name before ';' token|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiManager.h|33|error: expected class-name before '{' token|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiManager.h|58|error: 'wxsPositionData' does not name a type|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiManager.h|59|error: 'wxsSizeData' does not name a type|
E:\dev\codeblock_svn\wxpropgrid_debugger\src\plugins\contrib\wxSmithAui\wxAuiManager\wxsAuiManager.h|98|error: 'wxsCoderContext' has not been declared|
||More errors follow but not being shown.|
||Edit the max errors limit in compiler options...|
||=== Build finished: 50 errors, 118 warnings ===|

Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on April 26, 2010, 09:50:32 pm
FWIW, I got around the issue of previous post by copying some portion of the contrib items to/from the trunk path.  It appears that I renamed the *wxsmith* items from the wspropgrid branch out of the way, and copied their replacements from the current trunk release candidate.  After that I seemed to get a complete plugins contrib build without errors.  (I waited too long to come back and add this note, but I currently think that's what I did.)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on May 06, 2010, 05:21:35 pm
I've just found a problem in the shutdown procedure of C::B

Code
void MainFrame::OnApplicationClose(wxCloseEvent& event)
{
.......
    if (!Manager::IsBatchBuild())
    {
        m_pInfoPane->Destroy();
        m_pInfoPane = 0L;
    }

    Manager::Shutdown(); // Shutdown() is not Free(), Manager is automatically destroyed at exit


And the problem is: the log & info notebook is destroyed (all child logger controls too) before all plugins are destroyed/unloaded.
The result is that the logger system has pointers to destroyed objects => we get a crash every time such a pointer is used (for example in TextCtrlLogger::Append).

How should this problem be fixed?
1. Move the notebook's destruction below the Manager::Shutdown(); call
2. Add a method to the LogManager -> MarkAsDestroyed, which does  "control = NULL"
3. Something else
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on May 28, 2010, 01:19:07 am
Next patch is ready:
http://smrt.is-a-geek.org/codeblocks/dbg_refactor0014.2.patch

1. Fix watch parsing (GtkStyle, wxAuiTabArt)
1.1. Now prints an error message in the watches window if the parsing fails. If you see this string please report it as a bug
1.2. I've made an unittest project for the parser (it uses unittest++) if anyone is interested I can provide it
2. Made the "add watch" menu option to use the selection if there is such
3. SyncEditor now shows better error messages (code is refactored)
3.1. Clicking on a frame that points to a missing file now shows an info window with the error message
4. Made cbDebuggerPlugin::ShowLog to check if the Debugger's debug log is visible, if it is the method doesn't switch to the "Debugger" log tab (added some code in the log manager)
5. Attach/Detach from process was reimplemented
5.1. Added a menu on the stop toolbar button with two options: "detach from process" and "kill debuggee"
6. If a project fails to build a message is shown asking the user if he/she wants to debug the program (useful when a unittest project fails in the tests)
7. Don't show the editor tooltip if the mouse is outside the current active editor
7.1. Don't show the debug value tooltip if the user has moved the mouse
8. Improvements for the watches window
8.1. Made the popup window for value of a watch to be some kind of a singleton
8.2. Made the popup window to refresh when stepping through the code
8.3. Made the button that shows the window to have a tooltip. This tooltip should explain the advanced features of the button
9. Fixed a bug  - "closing C::B while debugging a project produces wrong message"

Please test...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on May 28, 2010, 06:57:33 am
http://smrt.is-a-geek.org/codeblocks/dbg_refactor0014.2.patch
Woot - you've been working hard obviously... Happy to hear that!

1.2. I've made an unittest project for the parser (it uses unittest++) if anyone is interested I can provide it
If you want to have it added to SVN, like we did with the ParserTest project on the cc branch I can do it. I think it's just convenient to have it in one place. (We actually should have test projects for the core and all other plugins, too... ;-)).
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on May 28, 2010, 10:11:03 am
If you want to have it added to SVN, like we did with the ParserTest project on the cc branch I can do it. I think it's just convenient to have it in one place. (We actually should have test projects for the core and all other plugins, too... ;-)).
Maybe you the devs should choose a testing framework for C::B.
Then I can redo the tests if the framework is other than unittest++.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on May 28, 2010, 09:49:18 pm
Maybe you the devs should choose a testing framework for C::B.
I guess most of us use unittest++, so this would most likely be the candidate.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on June 29, 2010, 01:08:34 am
OK, two new patches:

http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0015.0.patch
1. Catching exceptions should work now.
2. Added command to disable the feature of gdb to shorten the lines in the output from commands.
    This should improve the reliability of the plugin.

http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0015.1.patch
CDB related patch:
1. Implemented switching to frame.
2. Implemented step into, step out (thanks blueshake).
3. Implemented watches. If anyone knows how to print the content of array in cdb, I can improve the watches. Now it prints the first element (most of the time).
4. Improve the handling of current position.

Tested with VC 9.1 aka VC 2008sp1, debugging tools "Previous Release version 6.11.1.404 - March 27, 2009"
Anyone interested in the CDB, please test and supply patches for features that don't work (there are plenty of them)
I'm running linux most of the time and on windows I use gcc + gdb, so I can't test CDB's integration in "production", much.

Morten, after this patch I suppose the branch could be merged in trunk...  :lol: 8)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on June 29, 2010, 03:05:03 am
OK, two new patches:

http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0015.0.patch
1. Catching exceptions should work now.
2. Added command to disable the feature of gdb to shorten the lines in the output from commands.
    This should improve the reliability of the plugin.

http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0015.1.patch
CDB related patch:
1. Implemented switching to frame.
2. Implemented step into, step out (thanks blueshake).
3. Implemented watches. If anyone knows how to print the content of array in cdb, I can improve the watches. Now it prints the first element (most of the time).
4. Improve the handling of current position.

Tested with VC 9.1 aka VC 2008sp1, debugging tools "Previous Release version 6.11.1.404 - March 27, 2009"
Anyone interested in the CDB, please test and supply patches for features that don't work (there are plenty of them)
I'm running linux most of the time and on windows I use gcc + gdb, so I can't test CDB's integration in "production", much.

Morten, after this patch I suppose the branch could be merged in trunk...  :lol: 8)


You have done a wonderful achievement. :D
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on June 30, 2010, 12:42:59 am
One more change I have in my working copy is this:

Code
===================================================================
--- sdk/globals.cpp     (revision 6372)
+++ sdk/globals.cpp     (working copy)
@@ -210,6 +210,9 @@
 {
     wxString ext = filename.AfterLast(_T('.')).Lower();
 
+    if (ext.find(wxT('/')) != wxString::npos)
+        return ftHeader;
+
     if (ext.IsSameAs(FileFilters::ASM_EXT) ||
         ext.IsSameAs(FileFilters::C_EXT) ||
         ext.IsSameAs(FileFilters::CC_EXT) ||
Index: sdk/cbplugin.cpp
===================================================================
--- sdk/cbplugin.cpp    (revision 6372)
+++ sdk/cbplugin.cpp    (working copy)
@@ -254,7 +254,7 @@
         }
     }
     FileType ft = FileTypeOf(filename);
-    if (ft != ftSource && ft != ftHeader && ft != ftResource)
+    if ((ft != ftSource && ft != ftHeader && ft != ftResource) || line < 0)
     {
         if(log_index != -1)
         {

I've added it in order to enabled switching to frames inside headers from the C++'s standard library (vector, string, exception, etc).
I know this is not the right solution, but I'm not sure it if can be done without hacks.
Any suggestions are welcome and desired!
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on July 12, 2010, 11:50:27 am
OK, two new patches:
Applied and merged with trunk. The latter is untested... just take it as a warning. I just came back and have other things to do before testing this myself...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on July 12, 2010, 12:42:16 pm
Morten: Latter should be the CDB's patch, shouldn't it?
What about the header hack, do you know a better way to handle this?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on July 12, 2010, 04:22:30 pm
Morten: Latter should be the CDB's patch, shouldn't it?
Yes.

What about the header hack, do you know a better way to handle this?
I don't know a better way. A file without an extension could be ANYTHING. So it's really a hack and surely will introduce side-effects. The question is if these side-effects are critical and if the benefits are worth it.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on July 12, 2010, 05:33:49 pm
I could move this check to the cbDebuggerPlugin, so the damage could be limited a bit :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on July 18, 2010, 03:22:12 pm
The branch is broken :(

Code
Index: src/plugins/debuggergdb/cdb_driver.cpp
===================================================================
--- src/plugins/debuggergdb/cdb_driver.cpp      (revision 6402)
+++ src/plugins/debuggergdb/cdb_driver.cpp      (working copy)
@@ -191,7 +191,7 @@
     QueueCommand(new CdbCmd_InfoRegisters(this));
 }
 
-void CDB_driver::SwitchToFrame(size_t /*number*/)
+void CDB_driver::SwitchToFrame(size_t number)
 {
     ResetCursor();
     QueueCommand(new CdbCmd_SwitchFrame(this, number));
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: dmoore on July 21, 2010, 05:10:30 pm
I've just found a problem in the shutdown procedure of C::B

Code
void MainFrame::OnApplicationClose(wxCloseEvent& event)
{
.......
    if (!Manager::IsBatchBuild())
    {
        m_pInfoPane->Destroy();
        m_pInfoPane = 0L;
    }

    Manager::Shutdown(); // Shutdown() is not Free(), Manager is automatically destroyed at exit


And the problem is: the log & info notebook is destroyed (all child logger controls too) before all plugins are destroyed/unloaded.
The result is that the logger system has pointers to destroyed objects => we get a crash every time such a pointer is used (for example in TextCtrlLogger::Append).

How should this problem be fixed?
1. Move the notebook's destruction below the Manager::Shutdown(); call
2. Add a method to the LogManager -> MarkAsDestroyed, which does  "control = NULL"
3. Something else

Slightly O/T, but has this issue been resolved in C::B trunk? I think this was a cause of crashes on exit with my FileManager plugin (which was using the logs to show some debugging info).
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on July 21, 2010, 05:18:27 pm
I think it isn't
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on July 22, 2010, 07:31:39 am
Slightly O/T, but has this issue been resolved in C::B trunk? I think this was a cause of crashes on exit with my FileManager plugin (which was using the logs to show some debugging info).
I wasn't aware of that (or missed it).

1. Move the notebook's destruction below the Manager::Shutdown(); call
I would simply prefer that solution. Did you try, if that works?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on July 22, 2010, 09:16:31 am
I would simply prefer that solution. Did you try, if that works?
I'm not sure, but I think haven't.
I could try it.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on August 06, 2010, 05:26:08 am
a silly question:

If the new debugger plugin use the "MI" interface, can we still enter some command in “CLI” mode as the current implementation?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on August 06, 2010, 09:32:41 am
If the new debugger plugin use the "MI" interface, can we still enter some command in “CLI” mode as the current implementation?
Yes you can, look at the gdb docs for details.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on August 06, 2010, 01:43:50 pm
Yes you can
Ok, this is an enough good answer. :D thanks.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on August 15, 2010, 01:51:59 pm
Next patch: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0015.2.patch

1. fixes formatting
2. improves the parsing of watch variables

Unittest project for the debugger plugin: http://smrt.is-a-geek.org/codeblocks/patches/dbg/test_dbg.zip

1. extract the zip file in the src/ directory
2. add the test project in a workspace with the codeblock-unix.cbp
3. make codeblocks to depend on the test project

The provided project is linux only and requires unittest++ to compile.

Any feedback is welcome
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on August 22, 2010, 09:39:28 pm
OK, Next patch: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0016.0.patch

What it does:
1. Adds another command step into instruction.
1.1. Added toolbar button (please add the proper icons from the nightly thread)
1.2. Added menu item
2. Rearranges the icons on the toolbar a bit
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on August 23, 2010, 12:12:27 am
And another one: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0016.1.patch

Fixed this bug:

(http://img163.imageshack.us/img163/2038/debuggingwindows.th.png) (http://img163.imageshack.us/i/debuggingwindows.png/)

At first no window was ticked. I clicked on "Watches" (which was already visible), and it go its tick. Disassembly window was not shown. I clicked on it, I got it, and the tick was also there. CPU Registers was shown from the beginning, never clicked it, never got the tick.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on September 02, 2010, 05:03:43 pm
FWIW -

In svn branch wxpropgrid_debugger, file plugins\debuggergdb\gdb_commands.h, "class GdbCmd_TooltipEvaluation", routine "void ParseOutput(const wxString& output)", toward the end of the routiine, I think there is a problem with the variable s_pWin.

It appears some code was added (relative to current trunk) to avoid invoking the tipwindow if the mouse has moved.  As a result of that addition, it seems s_pWin can be left with a value of an item that was "Close()"ed in a previous iteration, such that subsequent attempts to "Close()" that old item could occur, which might be a bad thing.

Didn't see anywhere else where s_pWin was being cleared to avoid this potential problem, but I may be overlooking something - and I don't know for sure that the "Close()" will render the item invalid, but...

it looks suspicious to me.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 02, 2010, 05:07:39 pm
Will look at it...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 03, 2010, 02:33:41 am
Next patch: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0016.3.1.patch

1. Added s_pWin = NULL in GdbCmd_TooltipEvaluation::ParseOutput
2. Added the check if the terminal opening has finished in a loop. The terminal should open faster. Also it should be detected correctly if it is started on a slower computer.
3. Fixed parsing of std::string = "test,test" in the watches window
4. Fixed "Catch exception" on windows
5. Fixed some "Do not run debuggee bugs"
5.1. "tbreak" command was emitted, when the debug/continue button was hit
5.2. "run" command was emitted, when in remote debugging mode, now emits the correct "cont"
5.3. "start" command was emitted, now the correct "run" is emitted

Test please :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 05, 2010, 03:40:37 pm
Next patch: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0016.4.patch

1. Combined "Debug -> Start" and "Debug -> Continue" in one menu item
2. Moved "Debug -> Run to Cursor" below "Stop debugger"
3. Implemented interrupting the debugger while remote debugging (see this thread for details http://forums.codeblocks.org/index.php/topic,12412.0.html )
4. Fixed a warning

Test again please...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 09, 2010, 07:45:45 pm
BTW: Did you already try the new official 7.2 debugger from MinGW?!

http://sourceforge.net/projects/mingw/files/MinGW/BaseSystem/GDB/GDB-7.2/gdb-7.2-1-mingw32-bin.tar.lzma/download
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 09, 2010, 08:16:29 pm
No, it is not available in gentoo, for some reason :(
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 11, 2010, 10:54:06 pm
Next patch: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0016.5.patch

1. Fixed some bugs related to the auto switch mode
1.1. Switch to the valid frame even when the backtrace windows is closed
1.2. If we're doing to update the backtrace, don't sync the editor. This prevents a popup to show when it is not needed.
2. Autosize the File column in the backtrace window

Morten, please merge trunk to debuggers branch, so I can test the fix for the loggers...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 12, 2010, 01:16:33 am
Morten: can you revert the change in MainFrame::ScanForPlugins() in r5795?
I've accidentally removed the code that searches for plugins in the user's directory, bad me, bad :(

The change should be something like this:
Code
Index: src/src/main.cpp
===================================================================
--- src/src/main.cpp    (revision 6571)
+++ src/src/main.cpp    (working copy)
@@ -1010,11 +1010,16 @@
 
     PluginManager* m_PluginManager = Manager::Get()->GetPluginManager();
 
-    // global paths
-    wxString path = ConfigManager::GetPluginsFolder(true);
+    // user paths first
+    wxString path = ConfigManager::GetPluginsFolder(false);
     Manager::Get()->GetLogManager()->Log(_("Scanning for plugins in ") + path);
     int count = m_PluginManager->ScanForPlugins(path);
 
+    // global paths
+    path = ConfigManager::GetPluginsFolder(true);
+    Manager::Get()->GetLogManager()->Log(_("Scanning for plugins in ") + path);
+    count += m_PluginManager->ScanForPlugins(path);
+
     // actually load plugins
     if (count > 0)
     {
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 12, 2010, 10:56:05 am
Morten: can you revert the change in MainFrame::ScanForPlugins() in r5795?
Done.

BTW: In fact I was always curious about that change and never applied it in my local copy. But I forgot to discuss this with you. Glad it's solved now. :-)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 12, 2010, 12:38:14 pm
BTW: In fact I was always curious about that change and never applied it in my local copy. But I forgot to discuss this with you. Glad it's solved now. :-)
It seems I've made this change, because without it CB can't find the core plugins when starting it from inside C::B...
And I don't know why...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 13, 2010, 09:24:23 pm
It seems I've made this change, because without it CB can't find the core plugins when starting it from inside C::B...
And I don't know why...
Guess what: it's the same for me on Linux now. :-( but only Linux. Did you talk about Windows?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on September 13, 2010, 11:04:52 pm
It seems I've made this change, because without it CB can't find the core plugins when starting it from inside C::B...
And I don't know why...
Guess what: it's the same for me on Linux now. :-( but only Linux. Did you talk about Windows?
Works fine here if compiled from inside, does not work (and can not work) if compiled with automake-system, because the directory layout is different.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 13, 2010, 11:18:31 pm
Jen: trunk or debuggers branch?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on September 14, 2010, 12:19:51 am
Jen: trunk or debuggers branch?
Both (tested with actual trunk and actual dbg-branch on debian 64-bit) !
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 14, 2010, 01:07:00 am
The problem seems to happen only when you have a plugin in the ~/.codeblocks directory.
When I've removed the plugin, CB could find the core plugins.
Probably a chdir is executed somewhere and the relative path to the global plugins is not correct any more.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 14, 2010, 01:29:18 am
Next patch: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0016.6.patch

1. Fixed bug http://developer.berlios.de/bugs/?func=detailbug&bug_id=15209&group_id=5358
2. SyncEditor should work for files without extension (files from STL)
3. Made warnings in the loggers blue, it was needed for the debugger's debug log in the gdb_mi plugin
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on September 14, 2010, 08:33:24 am
The problem seems to happen only when you have a plugin in the ~/.codeblocks directory.
When I've removed the plugin, CB could find the core plugins.
Probably a chdir is executed somewhere and the relative path to the global plugins is not correct any more.
Works also, even if I have a plugin in ~/.codeblocks:

Code
[...]
Scanning for plugins in /home/jens/.codeblocks/share/codeblocks/plugins
Loaded 1 plugins
Scanning for plugins in /home/jens/codeblocks-build/codeblocks.dbg/src/output/share/codeblocks/plugins
Loaded 11 plugins
[...]

debugger-branch without contrib-plugins.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 14, 2010, 09:21:53 am
Jens: What plugin have you installed? Mine was freshly created by the project wizard...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on September 14, 2010, 09:41:45 am
Jens: What plugin have you installed? Mine was freshly created by the project wizard...
The attached one.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on September 14, 2010, 07:12:33 pm
c::b/gdb file/path issues

Please see:
http://forums.codeblocks.org/index.php/topic,13306.new.html#new

(separate thread chosen, since may be outstanding trunk/gdb issue, rather than branch specific.)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 14, 2010, 11:02:16 pm
Next patch: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0017.3.patch

This patch is pretty experimental, so please review it carefully before application!!!

1. Added GetIsRunning method to ProjectManager, it is used to query the plugin that is running the project (running the application, debugging the application, etc)
2. Added SetIsRunning method to ProjectManager, it is used to set the plugin that is running/executing the project, it is set only if the GetIsRunning returns NULL
3. Modified the Compiler plugin to use the new methods (set and reset correctly the running flag, modified the toolbar/menu updateui functions)
4. Modified the Debugger plugin to use the new methods (set and reset correctly the running flag, modified the toolbar/menu updateui functions)
5. Changed a bit the accelerators for debugging (safe to apply this part of the patch)
6. Some formatting changes in cbDebuggerPlugin::RunNixConsole

I'm running C::B with this patch and I've fixed most of the problems, but I'm sure there are more...
Please test and provide feedback.

p.s. if this patch is accepted, some of the plugins should be modified to use the new methods (valgrind, cppcheck, cccc....)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 15, 2010, 07:31:31 am
Next patch: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0017.3.patch
[...]
This patch is pretty experimental, so please review it carefully before application!!!
[...]
p.s. if this patch is accepted, some of the plugins should be modified to use the new methods (valgrind, cppcheck, cccc....)
Ok, so I won't commit for now and test myself. Others (volunteers), please do the same

The question is: Who does the required changes for the other plugins? Do you already have a patch for this?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 15, 2010, 08:37:33 am
No, I don't have a patch, but I could do it later...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 15, 2010, 11:09:30 pm
Next stable patch: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0016.7.patch

1. Fix the Native problem from here: http://forums.codeblocks.org/index.php/topic,13272.new.html
2. Added log message if the debuggee can't be found
3. Improved the accelerators for the debug menu

Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 16, 2010, 12:01:59 am
Another stable patch: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0016.7.1.patch

All changes from the previous patch plus:
4. Fixed the examine memory parser problem described here: http://forums.codeblocks.org/index.php/topic,13273.new.html
5. Replaced \\t with \t, because it seems that wxRegEx doesn't support '\\t' by default, wxRE_ADVANCED should be used
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 16, 2010, 07:19:05 am
Another stable patch: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0016.7.1.patch
The other one (http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0017.3.patch) now won't apply anymore btw...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 16, 2010, 08:43:43 am
Yes, the patches has duplicate changes, if you remove the duplicates it should apply :)
If not I'll fix it tonight...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 17, 2010, 02:29:50 am
Next stable patch: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0016.8.patch

1. Added UpdateUI event for the controls used for sending commands to debugger.
2. Commands send from the normal log ("Debugger") print their result to both logs.
3. Some cleaning

Please test
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on September 17, 2010, 08:29:23 pm
Is there currently a debugging step capability within something like the disassembly window?

If not, do you have any plans, or know if others do, to add one?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 17, 2010, 08:42:05 pm
Have you tried the "next instruction" and the new "step into instruction" commands?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on September 18, 2010, 01:27:09 am
No - hadn't taken note of those.  Maybe because when I use them (I might have tried them before), while stepping does seem to occur, and I see the related actions in the Debugger (debug) log panel, I don't see any results anywhere else.

Is there some visual tracking of the process available outside of the log panel?  If so, where, how activated?  (I've looked at the Debug disassembly window, and it doesn't seem to be tracking anything there.)

Thanks.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 18, 2010, 02:46:56 am
Is there some visual tracking of the process available outside of the log panel?  If so, where, how activated?  (I've looked at the Debug disassembly window, and it doesn't seem to be tracking anything there.)
You've to see the same yellow arrow in the Disassembly window, as with the normal editor.

If you don't see it, please post details in this thread: http://forums.codeblocks.org/index.php/topic,12873.new.html
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on September 18, 2010, 05:28:07 am
If you don't see it, please post details in this thread: http://forums.codeblocks.org/index.php/topic,12873.new.html
didn't see it.
observations posted.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 19, 2010, 09:42:12 pm
Morten:
this change is wrong, please revert it:

Code
obfuscated@xlad ~/projects/codeblocks/brances/wxpropgrid_debugger $ svn diff -r PREV:HEAD src/sdk/loggers.cpp 
Index: src/sdk/loggers.cpp
===================================================================
--- src/sdk/loggers.cpp (revision 6605)
+++ src/sdk/loggers.cpp (revision 6608)
@@ -103,7 +104,6 @@
 
     style[success].SetTextColour(BlendTextColour(*wxBLUE));
 
-    style[warning].SetTextColour(BlendTextColour(*wxBLUE));
     style[warning].SetFont(italic_font);
 
     style[error].SetFont(bold_font);
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 20, 2010, 07:09:41 am
this change is wrong, please revert it:
Code
-    style[warning].SetTextColour(BlendTextColour(*wxBLUE));
     style[warning].SetFont(italic_font);
It's not applied anyways in the debugger branch's HEAD. :-)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 20, 2010, 09:21:23 am
It was applied...  :?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 20, 2010, 09:25:22 am
It was applied...  :?
It was removed during the merge... Probably not on purpose, but it's OK as it seems. :-)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 20, 2010, 10:54:10 am
It was removed during the merge... Probably not on purpose, but it's OK as it seems. :-)
I've added the change because in the gdb_mi plugin it was not OK, I don't know why.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on September 20, 2010, 06:20:01 pm
Obfusc, have you overlooked:
http://forums.codeblocks.org/index.php/topic,12501.msg89687.html#msg89687

or just not had time, or (relatively sufficient) interest?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 20, 2010, 06:28:50 pm
No time, it is on the TODO...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 20, 2010, 11:43:56 pm
Next patch: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0016.9.patch

Two disassembly problems:
1. No disassembly was displayed if gdb emits some warnings before the real result from the "info frame" command
2. There was no yellow marker on windows. It seems that %p doesn't generate 0x in front of the printed address in wxString::Format.

There many more problems with the disassembly window, but at least it is a bit more usable now.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 24, 2010, 06:39:03 pm
no pch patch:

Code
Index: src/sdk/cbplugin.cpp
===================================================================
--- src/sdk/cbplugin.cpp        (revision 6634)
+++ src/sdk/cbplugin.cpp        (working copy)
@@ -22,6 +22,9 @@
     #include "editormanager.h"
     #include "cbeditor.h"
     #include "projectmanager.h"
+    #include "infowindow.h"
+    #include "macrosmanager.h"
+    #include "configmanager.h"
 #endif
 
 #include <wx/toolbar.h>
Index: src/sdk/watchesdlg.cpp
===================================================================
--- src/sdk/watchesdlg.cpp      (revision 6634)
+++ src/sdk/watchesdlg.cpp      (working copy)
@@ -9,9 +9,11 @@
 
 #include "sdk_precomp.h"
 #ifndef CB_PRECOMP
+    #include <wx/dnd.h>
     #include <wx/menu.h>
     #include <wx/sizer.h>
 
+    #include "cbexception.h"
     #include "cbplugin.h"
     #include "logmanager.h"
     #include "scrollingdialog.h"
Index: src/plugins/debuggergdb/cdb_driver.cpp
===================================================================
--- src/plugins/debuggergdb/cdb_driver.cpp      (revision 6634)
+++ src/plugins/debuggergdb/cdb_driver.cpp      (working copy)
@@ -8,6 +8,11 @@
  */
 
 #include <sdk.h>
+
+#ifndef CB_PRECOMP
+    #include "logmanager.h"
+#endif
+
 #include "cdb_driver.h"
 #include "cdb_commands.h"
 

Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 24, 2010, 10:55:29 pm
Next patch: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0016.10.patch

1. Added tooltips to the watches window
2. Enabled the tooltips in the wxPG, please fix the windows project to enable them, too

Morten do you plan to add the svn tree, the test project for the debugger plugin?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on September 27, 2010, 11:24:12 pm
There many more problems with the disassembly window, but at least it is a bit more usable now.

Here's a patch to hopefully improve the disassembly stepping display (some fixes, some enhancements.)
1)Avoid unnecessary re-disassembling
2)change (correct?) check for "current" line address
3)correct code that checked for UpdateBackTrace() and then updated disassembly window
4)Changes to window "current" line position handling
5)support for mixed mode disassembly (currently only available as compilation option)
6)Add calls to NotifyCursorChanged() for cmd_step_instr and cmd_step_into_instr

Anybody interested in trying this?  (so far I've only tried winxp sp2, wxwidgets 2.8.10)

patch against wxpropgrid_debugger branch svn R6634
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 28, 2010, 07:31:54 am
Anybody interested in trying this?  (so far I've only tried winxp sp2, wxwidgets 2.8.10)
@oBFusCATed: Will you look into this?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 28, 2010, 08:27:58 am
Yes, I'll tonight (but I don't use disassembly much(at all in fact))... If I don't answer soon please remind me.

Btw this one looks bad
Code
@@ -117,33 +120,83 @@
     wxString fmt;
     fmt.Printf(_T("%p\t%s\n"), (void*)addr, line.c_str());
     if (!fmt.StartsWith(wxT("0x")))
-        fmt = wxT("0x") + fmt;
+        fmt.insert(size_t(0), &wxT("0x")[0], wxString::npos) ; //n == npos, insert all of sz
Why it is needed? what it does?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on September 28, 2010, 09:49:47 am
Yes, I'll tonight (but I don't use disassembly much(at all in fact))... If I don't answer soon please remind me.

Btw this one looks bad
Code
@@ -117,33 +120,83 @@
     wxString fmt;
     fmt.Printf(_T("%p\t%s\n"), (void*)addr, line.c_str());
     if (!fmt.StartsWith(wxT("0x")))
-        fmt = wxT("0x") + fmt;
+        fmt.insert(size_t(0), &wxT("0x")[0], wxString::npos) ; //n == npos, insert all of sz
Why it is needed? what it does?

[edit]
"what it does?" - it inserts the passed string into position zero of the existing string, without requiring a new buffer/object allocation, when the existing buffer is already large enough to hold the .insert()d string. [/edit]

Not required, but was trying to avoid the extra object construction (in original code) of extra wxString (and its buffer allocation) on every added line, when the existing allocated buffer might be enough for the extra two characters.  In wxWidgets 3.0 (well, 2.9.x), the internals of .insert have changed, its started doing an ('...substring') local object allocation, so any improvement from this might be negated by environment code changes in next major wxWidgets release**.  The ugly casts were trying to get the correctly overloaded .insert from among the compiler ambiguities (there might be a cleaner way to achieve that, I didn't go beyond getting the one I wanted.)

... (but I don't use disassembly much(at all in fact))...
What!!!???!! Oh, you surely miss much... :)

**I probably should take a closer look at that change, and see if its avoidable and if I could convince the wxWidgets devs to eliminate it if reasonably possible, but I only have so much time, and its not a lot.  (I do use disassembly a lot, in other products, hence the time spent here.)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 28, 2010, 10:24:18 am
Have you profiled the code?
What improvement in performance do we get by this change?
If it is less than 15% (I'm sure it is less), please leave it as it is.

Also in c++0x this won't be an issue (I think).

p.s. There is one general rule: premature optimization is the root of all evil.
p.p.s. memory allocations are not problem on the PC for most GUI applications
p.p.p.s. I don't need to look into the assembly to fix most of the problems I encounter and I don't do much hardcore optimization work.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on September 28, 2010, 10:29:50 am
Anybody interested in trying this?  (so far I've only tried winxp sp2, wxwidgets 2.8.10)

patch against wxpropgrid_debugger branch svn R6634

Meant to also note - GDB (7.1, maybe 7.2 also), or GDB/c::b, seem to have issues (at least in the 'mixed' mode) when attempts are made to step into code where GDB cannot find the source.  I've seen GDB seemingly fail to actually perform the step (looking at debugger(Debug) log window), I've seen it do the step but c::b can't update display because GDB returns 'internal error' warnings about psymtab vs symtab inconsistency (from a 'bt' request), and I've seen it seem to work.  I've particularly seen  that occur with a routine _Unwind_SjLj_register (something like  that), but I think also when it looked for other library modules (which I don't have source for locally) that contained two separate relative path segments (don't currently recall module name) in the debug info filename.

So if you see something strange, check debug log window for gdb output to be sure problem not related to something its doing, or not doing.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on September 28, 2010, 11:40:45 am
disclaimer:  This is NOT intended to be inflammatory, nor particularly defensive, just informative.  Please read it with that mindset.

Have you profiled the code?
No, not in this context.
What improvement in performance do we get by this change?
Probably less than 15% yes, but it is combined unnecessary actions like this that add up throughOUT a program to make it slower, and profiling can't really reveal the effect of those, because they're so spread out.  Add'l heap fragmentation also tends to slow down everybodies allocations over time.  (I've worked on this on a machine that can see c::b/GDB take approx. 20-30 minutes to load c::b for debugging - when I reboot the machine it takes <= 30 seconds.  As best I can tell, its probably because of OS virtual memory address space fragmentation, that is eliminated by a reboot.)

While the total disassembly time improvement is likely less than 15%, I'd estimate the local operation percentage gain (of orig. string concat vs .insert) to be possibly 50% gain, but if you like I'll consider* trying to cobble together something to demonstrate this - although it'll be a little harder to prove in a single-threaded context, whereas the effect can be more pronounced in multi-threaded contexts where multiple threads may be thrashing the heap with allocations.  (c::b does seem to have multiple threads doing something.)  (*Not that I really want to spend my time proving this, for something I know is a wise practice, when the product itself could benefit from further changes.)

I might also note that the original addition of the check for the leading '0x' might have been avoided, with the code and formats being modified for all environments.  Of course the trade-off is consistency in all environments (windows vs linux vs ?), vs faster performance vs code maintainability vs risk of changes made to solve original problem.  (The current code is probaby 'faster' in linux, because it doesn't have to perform the extra object allocation, both environments have overhead of checking to see if '0x' there to begin with, slower in windows where the object construction and concat are performed, and those lines are less 'maintainable' as there is an 'exception' path ["Is there a leading 0x? No, add one"] that nothing in the code currently indicates the reason for.  (Its also dependent on output that is obviously currently different in different environments, and thus probably subject to future change, since it might reasonably be expected to be the same.)  (Modification might have been to eliminate use of %p, just use %x and add leading literal '0x' as in '0x%08x', but that could be a problem for 64-bit environs, if that's an issue.)  I saw what I thought was an opportunity for 'low-hanging fruit', albeit small in larger context, and took it.
If it is less than 15% (I'm sure it is less), please leave it as it is.
OK if you like, but see previous note in this response.
Also in c++0x this won't be an issue (I think).
Why not, what does c++0x provide to help this? 
When will c::b be distributed in c++0x (in all environs it serves)?


p.s. There is one general rule: premature optimization is the root of all evil.
Scattered failures to avoid unnecessary actions can result in 'fat' that cannot be easily detected or optimized away, short of a rewrite that avoids the unnecessary actions.

p.p.s. memory allocations are not problem on the PC for most GUI applications
The disassembly process itself is really a 'batch' operation within a GUI.  Try stepping into a very 'large' routine, and the pause waiting for disassembly is noticeable, and a bit long for pleasant GUI responsiveness.
p.p.p.s. I don't need to look into the assembly to fix most of the problems I encounter and I don't do much hardcore optimization work.
likewise, but I do at times find it indispensable, particularly when trying to debug optimized code that has failed.  I tend to prefer mostly working with code as it will be shipped, because I've chased too many problems (multi-threaded, timing-related problems) that simply would not show up in the non-optimized ('debug') code versions.  (And no, I've not generally been responsible for creating most of those problems, merely the one stuck with correcting them.)  Figuring out what's happening without looking at the disassembly of the optimized code has not been something I could accomplish.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 28, 2010, 12:11:38 pm
Also in c++0x this won't be an issue (I think).
Why not, what does c++0x provide to help this? 
Rvalue references. The temporary should be reused if the classes are written right, but I'm not sure if this is true, have to check it.

The disassembly process itself is really a 'batch' operation within a GUI.  Try stepping into a very 'large' routine, and the pause waiting for disassembly is noticeable, and a bit long for pleasant GUI responsiveness.
Haha, this is another problem an has nothing to do with filling the Disassembly window - http://forums.codeblocks.org/index.php/topic,11298.0.html

p.p.p.s. I don't need to look into the assembly to fix most of the problems I encounter and I don't do much hardcore optimization work.
I've said that I don't use it much, so I can test the improvement in that area. I've not said that the disassebly windows is useless.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on September 28, 2010, 02:38:49 pm
Rvalue references. The temporary should be reused if the classes are written right, but I'm not sure if this is true, have to check it.
FWIW,

The original expression invokes a global operator+() function which declares a local wxString variable, and then calls a method operator+= to concatenate the items, before returning the result.

No temporary involved in that part of the process.

I think even if it were a temporary, it would be hard for a compiler to optimize away the internal buffer allocation involved in holding the string's actual data, and don't know how or if the class w/could be "written right" to avoid that.

(Unfortunately, as mentioned earlier/elsewhere, it appears that wxWidgets 2.9.x has changed the .insert to also involve the definition of a local class object, although I don't think that object involves a buffer allocation.)

You know, I thought about not trying to make that change, wondering if it would "raise a stink."  But I wasn't able to let it pass... :(
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on September 28, 2010, 02:57:14 pm
Haha, this is another problem an has nothing to do with filling the Disassembly window - http://forums.codeblocks.org/index.php/topic,11298.0.html
deleted - posted in the patch thread referenced in quote.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 28, 2010, 03:05:15 pm
It is not committed because it was not safe

The patch is here http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_speedup_test.patch
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 28, 2010, 06:27:02 pm
Yes, I'll tonight
Ok guys, I looked briefly into it and I think there are indeed some benefits like the update on disassembly (not the one oBFusCATed mentioned, but in general).

However, there are also some issues like querying the UI for a setting that probably should be exchanged through configmanager.

But in fact I have an issue now: If one of you posts a patch this will break the application of the other one in the debugger branch. So I would love to see you both agree on one patch whenever something is ready.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on September 28, 2010, 09:22:06 pm
However, there are also some issues like querying the UI for a setting that probably should be exchanged through configmanager.
Which setting?
The "mixed" mode?
(Considering right-click popup context menu in disassembly for short-term access, but haven't attempted yet.)
Something else? 

But in fact I have an issue now: If one of you posts a patch this will break the application of the other one in the debugger branch. So I would love to see you both agree on one patch whenever something is ready.
Understood.  Obfus is definitely the current driving force here.

 I expect to piggyback off him, although I'm not sure there are any outstanding patches you haven't already applied to branch - although I haven't examined that carefully.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on September 30, 2010, 05:06:44 am
Add "Mixed Mode" checkbox to disassembly dlg to enable/disable mixed mode disassembly display.  
(Actual display support of mixed mode disassembly already existed in previous patch.)

Previously considered context menu is apparently already created/owned by the control displaying the disassembly lines, and I could figure out how to do this quicker than I could figure out how to gain access to that child's context menu.

This patch is cumulative, containing all changes of first disassembly changes patch.

[edit]
Not so funny to poor, tired me :( (the file was on my disk, and not zero bytes, not sure what happened)

hopefully it will be there after this save

sorry Morten
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 30, 2010, 08:10:44 am
This patch is cumulative, containing all changes of first disassembly changes patch.
Funny: This patch has 0 bytes. :P
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on September 30, 2010, 10:59:38 am
patch now has non-zero bytes, 2nd post above - bumping thread for forum visibility.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on September 30, 2010, 09:24:51 pm
Hi all! Just for your interest: I've merged trunk into the branch again, as there were many new features and important bug-fixes. Revision 6647 (by Jens) caused trouble in terms of conflicts as I has expected. What I did to resolve the issues was keeping the branch's revision, so this bug fix didn't make it into the branch therefore! Probably oBFusCATed can have a look at it?!

@cbexaminr: Your patch shouldn't be affected... but you should better try again to make sure...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 30, 2010, 11:28:13 pm
Morten: the branch is not affected by this bug, because the cbWatch/GDBWatch objects are stored in std::vector<std::shared_ptr<GDBWatch> >, so they are reference counted and the pointer is valid in the Command::ParseOutput
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on September 30, 2010, 11:48:10 pm
cbexaminr: some comments on the patch:

Code
         GdbCmd_Disassembly(DebuggerDriver* driver)
             : DebuggerCmd(driver)
         {
+            //TBD: Should this be 'fixed' to a position, something like
+            //"disassemble $pc" ?  I think a user messing with the debug console and disassemble
+            //could foul up the result, with that missing, but not certain...
+            cbDisassemblyDlg *dialog = Manager::Get()->GetDebuggerManager()->GetDisassemblyDialog();
             m_Cmd << _T("disassemble");
+            if(dialog->MixedMode())
+                //gdb's ordering of instructions with /m can be pretty confusing...
+                m_Cmd << _T(" /m") ;
         }

1. Progably dialog->MixedMode(), should be moved to DebuggerManager::GetMixedMode()/IsMixedMode();
2. Change the constructor from GdbCmd_Disassembly(DebuggerDriver* driver) to GdbCmd_Disassembly(DebuggerDriver* driver, bool mixedMode) and do "if(dialog->MixedMode())" only once;
3. I think the user can't fool the disassembly, because he can't enter commands while the output is processed (If it can please show how)
4. use "svn diff -x '-u -b'" to generate the patch because you've messed the formatting of src/sdk/resources/disassembly.xrc
5. else and if should be on one line, and there is a space between if and (
6. why don't you use a proper container for m_LineTypes (std::vector<LineTypeEnum>, wxArray something... (vector<bool> is not proper container in c++ < 0x) )?

I've not done any testing, but will do tomorrow ...

Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on October 01, 2010, 07:06:28 am
cbexaminr: some comments on the patch:
I have tried to address your comments.

regarding 'mess' of .xrc file, I'll have to implicate M. (wx)Smith in that (or whatever resource editor is opened by c::b project.)

Added another button to 'quick' adjust current line position in display window.

When testing, remember my request to check the debugger log window when strange things happen.  (They probably will, they do for me.)

still needed -
1 gdbcmd_items for stepinstruction and stepintoinstruction with their own parseoutput()s and corresponding code in disassemblydlg to update the static function/line location at top.
2 observed anomalies corrected, or compensated for if gdb and/or /mi issues

anomalies observed, none 100% consistent to reproduce, but all have happened more than once, I was most recently running with local build of gdb 7.2, but have seen 1,2,3 and 4 with gdb 7.1 as well:
1 'wait for disassembly' message remains in window and no assembler code displayed
2 sometimes can be stepping instruction into/through routine with no update reflected in assembly window
3 sometimes can be stepping instruction but no stepping is occurring (debugger log seems to always shows gdb bt returning one of the messages about inconsistent psymtab vs symtab when this has occurred)
4 something like 'invalid line 0', with a display of some source file path and a number of lines (but no assembly code)
5 with mixed mode disassembly, gdb has entirely omitted some instructions from the disassembly (think in !~wxstaticbitmap() was one place I observed this (presumed gdb issue, log reflects omission), instructions are present when mixed mode disabled.

In at least one of the forms of no assembler displayed (dont remember which) log was showing gdb output with the 'dump of' header, and subsequent trailer, with no instructions in between.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on October 03, 2010, 07:49:59 am
oBFusCATed,

It appears the MI interface is not currently active in the debugger branch.  I reviewed the thread and see that your first steps were to re-work some of the class organization.

Assuming I'm correct that its not active...

Is it optionally available somehow/where?
If not, what are your current plans for actually beginning to use the MI interface?  (I tried the simple approach of turning it on, and quickly found that apparently most (all?) response handling will apparently have to be modified.)

(reason desired:
Trying to wxRegEx match source/line info from responses to nexti/stepi (for disassembly location header update) is entering regex territory I've not traveled before (attempting to use non-greedy specifiers, due to windows possibility of alternate data streams which can have ':'s embedded in paths, when the response string itself uses colons for field delimiters.) From docs, looks like it would be much easier to do this with the MI responses... :) 
)

Thanks.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on October 03, 2010, 09:26:08 am
It appears the MI interface is not currently active in the debugger branch.  I reviewed the thread and see that your first steps were to re-work some of the class organization.

true.

from this page:
Mode Options - Debugging with GDB (http://sourceware.org/gdb/download/onlinedocs/gdb/Mode-Options.html#Mode-Options)

The MI interface should be enabled by "--interpreter=mi" option, I just check the debug-log of debugger-branch, and there's no such option.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on October 03, 2010, 12:59:34 pm
I'm working on gdb/mi plugin, it can be found here:
Code
URL: svn://smrt.is-a-geek.org/cb_gdb_mi/debbugger_gdbmi
Repository Root: svn://smrt.is-a-geek.org/cb_gdb_mi

But at the moment requires, special patch in order to compile and work, will post it later...
p.s. at the moment gdb/mi plugin has the most basic actions/commands working (stepping/breakpoints/callstack/threads/watches), no disassembly, memory windows, no remote debugging
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on October 03, 2010, 02:06:03 pm
It appears the MI interface is not currently active in the debugger branch.  I reviewed the thread and see that your first steps were to re-work some of the class organization.
true.
Partially true. It's not in the branch, but you have to checkout the new debugger plugin from oBFusCATed's SVN server (svn://smrt.is-a-geek.org/cb_gdb_mi/debbugger_gdbmi).
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on October 15, 2010, 04:22:24 am
latest (gdb-related) disasm changes effort (hopefully not zero length the first time this time)

outstanding issue(s):
1)Does auto-switch still work properly?
2)'invalid' something or other message with no actual disassembly sometimes after activating mixed mode

annoyances (that I can't do much about from within c::b with current gdb interface - mi interface may hold some hope, don't know yet):
1)(still) too much (re-)disassembly, mostly because gdb sometimes doesn't provide instruction address in its responses) - some (re-disassembly) may be due to c::b code flow, but until that caused by absence of addresses from gdb output is fixed, not worth my time pursuing.  (But think original re-disassembled for every step, so some improvement.)
2)mixed mode (sometimes) missing instructions (gdb doesn't provide them), results in no 'current' line to indicate, because its not provided by gdb
3)Have seen disassembly output from gdb seem to have extra EOLs inserted - resulted in a disassembly display of '0xQQQQQQ call ' - the called address/routine was on the next line, but disassembly 'addline()' routines didn't expect that nor know how to handle - and I don't know whether that can be regularly expected, or is some sort of gdb output anomaly.

It appears that gdb may sometimes not realize that certain instructions 'belong' to certain lines of source.  (Don't know if this is gdb issue or compiler/linker issue.)  And this may be responsible for some of annoyances(1) and all of (2) above.

[edit]re-genned patch with -x "-u -b", forgot first time - but I'm not sure it changed the .xrc diff much if at all.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on October 15, 2010, 12:44:19 pm
outstanding issue(s):
1)Does auto-switch still work properly?
It works for me, if it doesn't work for you please provide details, how to reproduce it.

Sorry, I haven't much time to look at your patch, hope to do it next week, so it can be tested more...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on October 16, 2010, 11:49:51 am
relative to disasm.changes.4.patch

re-instate code to populate disassembly header info (erroneously removed)
changes to not break autoswitch but still disassemble last current step location
remove some garbage
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on October 22, 2010, 04:58:23 pm
For MSW/GDB, Pause-Break(/Stop) actions don't work when process has been 'attached'.  (Guessing similar could be true for non-MSW compilation path as well...?)

Appears can be corrected for MSW by addition in DebuggerGDB::DoBreak(bool temporary) of
if(pid <= 0) //Did child lookup succeed?
  pid = m_PidToAttach ;

in appropriate location after effort has been made to find 'child' in table, with failure

Also, is there a reason to continue searching table after a child has been found? Can there be more than one 'child' that would match? 

And, could log an error if one reported from call of DebugBreakProcess().

I've attached a patch _only for reference_ that includes changes that address most of these comments, BUT, it is also dirtied with other as yet unapplied items in my disasm patch(es).  (The changes pertinent to these comments are those in the DebuggerGDB::DoBreak() method.)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on October 22, 2010, 05:41:23 pm
Patches can be edited with a text editor, so you could remove the disasm-changes from your patch.
Also you could checkout the tree in another directory :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on October 22, 2010, 08:11:41 pm
relative to disasm.changes.4.patch
I'm afraid you'll need to re-do this for the current version in the branch as this has been modified heavily due to the merge. I am very sorry for this inconvenience.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on October 22, 2010, 08:46:59 pm
There is a build problem:
Code
/home/obfuscated/projects/codeblocks/brances/wxpropgrid_debugger/src/sdk/nullptr.cpp:16: error: ‘null_pointer_t’ does not name a type

It seems that the nullptr.cpp is not added to the trunk's Codeblocks-unix.cbp
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on October 22, 2010, 09:08:01 pm
I was composing a question regarding this... when you posted...

I suspect nullptr.cpp is supposed to be _removed_ from the project, as it appears that null_pointer_t definition has been removed from src/sdk/prep.h, and replaced with something different to define a const "nullptr" item directly in prep.h...

But I don't know... [edit] branch built for me after _removing_ nullptr.cpp from c::b project...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on October 23, 2010, 01:04:35 am
Here is http://smrt.is-a-geek.org/codeblocks/patches/dbg/pch_build_2010_10_22.patch the full patch I'm using to build the debugger branch.

I build without pch, so most of the patch is related to include fixes.
Loaden you owе me a virtual cake :-P


p.s. this patch could be applied to trunk with minor modifications, I've not tried it because I don't use trunk...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on October 23, 2010, 01:54:47 am
relative to disasm.changes.4.patch
I'm afraid you'll need to re-do this for the current version in the branch as this has been modified heavily due to the merge. I am very sorry for this inconvenience.

:( C'est la vie.

.5. patch redone after merge - plus...

Also includes the suggested changes and possible fix for pause-break(/stop) not working for 'attach'ed process.  Also has addition of guessed change for the non-MSW path, but that is not even compiled.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on October 23, 2010, 02:27:16 am
Please separate the patches...I'm sure it won't be too hard...

BTW the old patch is working without problems...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on October 23, 2010, 05:04:26 am
separated

plus tipwindow experimental changes patch, just in case you'd forgotten.  (I think its free of the eol property issues now as well.)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on October 23, 2010, 06:45:15 pm
cbexaminr:

Can you explain the steps needed to reproduce the bug you try to fix with the attachpause.2.patch ?

The disassembly patch seems to cause the output command for the tooltip to be executed 3 time, can you investigate that?

p.s. I'm running gentoo linux amd64, if this can make a difference
p.p.s. The DebugBreakProcess is available in win2000+, so the debugger can't work in win98/ME

Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on October 23, 2010, 08:03:38 pm
cbexaminr:

Can you explain the steps needed to reproduce the bug you try to fix with the attachpause.2.patch ?
On windows, Start c::b, attach to a process that you do not have a project open for, but which has been previously started outside of c::b.  An initial break will occur (on windows at least) as a result of the initial attachment.  Continue the target process from c::b.   Then attempt to 'pause' the running process (I was using the toolbar icon, don't think I tried the menu option.)

(Codewise, the process is not paused, because m_Pid is not populated for an attached process, and a child is not found to attempt the 'break' on.)

I'm assuming similar circumstances would occur on Linux as well, assuming m_Pid and m_AttachToPid are handled the same as windows, but I didn't actually explore this outside of DoBreak().

The disassembly patch seems to cause the output command for the tooltip to be executed 3 time, can you investigate that?
OK, I'll see what happens to me on windows. 

p.s. I'm running gentoo linux amd64, if this can make a difference
Don't know, could be some difference.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on October 23, 2010, 08:20:36 pm
Hm, works on linux, should do some testing on windows....

BTW, m_Pid is the PID of the debugger

p.s. the GdbCmd_StepOrNextInstruction and similar classes in the Disasm patch seems to be unused, can I remove them?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on October 23, 2010, 09:07:17 pm
The disassembly patch seems to cause the output command for the tooltip to be executed 3 time, can you investigate that?
OK, I'll see what happens to me on windows.  

Get three commands, but not repeats.

For a boolean variable bFirstTime, the three slightly different commands executed were:
whatis bFirstTime
output &bFirstTime
output bFirstTime

were all executed obtaining 1)type information, 2)address, and 3)variable contents.

Could that be what you are seeing?  The disassembly patch has nothing to do with that, though.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on October 23, 2010, 09:09:18 pm
p.s. the GdbCmd_StepOrNextInstruction and similar classes in the Disasm patch seems to be unused, can I remove them?

No.  I'm pretty sure you'll find they are used if you remove them and try compiling.  That one is a base for the other two commands.  At the moment they're similar, but I chose to give each action its own command class in case they should need to diverge.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on October 23, 2010, 09:16:32 pm
I don't need to compile it, in order to tell you that they are unused, at least in 5d.patch :) (tested with compiling, too)
Probably you have something different in you working copy.

Also, what do I need to do to reproduce the case, that requires the introdution of GdbCmd_ChangeFrame?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on October 23, 2010, 09:39:58 pm
include missed gdb_driver.cpp which invoked the descendant classes.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on October 23, 2010, 10:44:19 pm
Also, what do I need to do to reproduce the case, that requires the introdution of GdbCmd_ChangeFrame?
umm, umm, umm....

I can't remember precisely.  It has to do with stepping into code that you don't have a stack frame for, or don't have source information for, or perhaps either.  (I think it usually involved stepping into runtime library and or OS areas, although not all of them.)  The frame N command output was being trapped by the breakpoint stuff in that ParseOutput() routine, and resulted in a (re-)disassembly to a position that matched the source code ("first position found with matching source code" - autoswitch), rather than where the program was actually going to step next.  I was unable to find (doesn't mean there isn't one) a [edit]_reliable_[/edit] way to determine _what_ the next process instruction address was - the info frame and bt commands did not seem to always provide correct information, for certain frame(-less) situations.

I have been using the early tooltip demo program, breaking at the "if(bFirstTime)" line when the Hover button was pressed, and stepping from there.  There was one scenario in that process that eventually led me to the frame change changing the disassembly position as well as the source code change (because the frame change output looked like breakpoint output.)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on October 28, 2010, 12:04:20 am
Next patch: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0016.11.patch

Fixed bug:
Watch parsing fails when string/char contains many repeating characters (http://forums.codeblocks.org/index.php/topic,13337.msg90084.html#msg90084)

Morten: what's up with the test project for the debugger plugin?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on October 28, 2010, 06:50:47 am
Morten: what's up with the test project for the debugger plugin?
I'm afraid I don't exactly know what you mean? Which project?

And btw: What's up with the patch(es) of cbexaminr? If you want me to do, I can apply them for a nightly so we can see how it works. If there are major reasons / bugs detected we would be able to revert it easily and do another trial... any thoughts?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on October 28, 2010, 07:31:55 am
...btw: I am facing a very strange issue myself meanwhile. I cannot debug into a project which I've created (a simple console application) anymore. The application just "runs through" no matter if I've set a BP or say run to cursor or alike. It used to work previously but fails now.

This project uses many libraries, provided through other projects within the workspace. All I can tell is that compiling is correct (I am using -g, not stripping symbols or alike) hence the only thing I can imagine is that I also compile the application with profiling information.

Could it be that newer compilers (TDM 4.5.1) in combination with newer debuggers (7.2) and enabled porofiling information does not work abnymore? Anybody experiencing the same?!
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: killerbot on October 28, 2010, 07:47:49 am
occasionally it happens to me to that the debugger just races through th application and doesn't take the breakpoints into account. I haven't been able to see a structure in it though......
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on October 28, 2010, 08:33:08 am
occasionally it happens to me to that the debugger just races through th application and doesn't take the breakpoints into account. I haven't been able to see a structure in it though......
Yes - that's what happens to me, too. I wonder if it's the compiler/debugger, or the plugin though.
Strange thing is that in the debugger's debug log I see that all commands are actually setup correctly.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on October 28, 2010, 08:48:28 am
I'm afraid I don't exactly know what you mean? Which project?

This one: http://smrt.is-a-geek.org/codeblocks/patches/dbg/test_dbg.zip
And btw: What's up with the patch(es) of cbexaminr? If you want me to do, I can apply them for a nightly so we can see how it works. If there are major reasons / bugs detected we would be able to revert it easily and do another trial... any thoughts?
I will take a look tonight, I've some modifications to it (simple code style + simplifications)....

About the issue: look at the debuggers log for strange messages, warnings and so on. On windows gdb is quite unreliable and produces various errors and warnings, which are not expected by C::B and break the output parser.
Also try to debug with cmd line gdb, I know it is tough, but one has to do it sometimes :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: killerbot on October 28, 2010, 08:53:44 am
probably not related, but something I seem to always get (on a linux box) :
"warning: GDB: Failed to set controlling terminal: Operation not permitted"

My gdb : GNU gdb (GDB) SUSE (7.1-3.12)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on October 28, 2010, 09:27:12 am
This isn't problems... just ignore it...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on October 28, 2010, 11:16:43 pm
I'm afraid I don't exactly know what you mean? Which project?
Uf, I've forgot to tell you about the test project...
It can be found here: http://smrt.is-a-geek.org/codeblocks/patches/dbg/test_dbg.zip
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on October 29, 2010, 03:06:53 pm
Uf, I've forgot to tell you about the test project...
(actually, you didn't - it just got embedded into one of the quoted items [several posts before this one])
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on October 31, 2010, 12:40:36 am
cbexaminer: I've looked at your patch, at last...

Here are some general suggestions:
1. Don't use abbreviations for the identifiers
2. Use camel-case for the identifiers: "m_myVar" instead of m_myvar

I've modified the patch a bit: http://smrt.is-a-geek.org/codeblocks/patches/dbg/disasm_changes_mine.patch
1. I've cleaned the code a bit, the behaviour should not be changed, please verify it.
2. Added a check if the disassembly dialog is visible in the step command base class.
   The old patch was executing the disassembly command even if the dialog was closed.

More changes are required:
1. You should remove all the // TBD comments
2. You should improve the comments:
   I can hardly follow them, because you've written some random thoughts or used too many words and I'm getting lost.
   The comments should be short and clear.
3. A commit message will be needed - describe all the changes please...

Please do some cleaning and then I'll look at your patch again.
I've applied it in my local copy and I hope to do some development + testing tomorrow.

Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on October 31, 2010, 04:48:33 am
I've compared the diffs, and I did not see anything that would break the intended logical functionality I had.

I do wonder why you changed the formal parameter DebuggerDriver* type to the GDB_driver* type in the step/next classes, when everything else in gdb_commands.h is receiving a parameter type of DebuggerDriver* ?

I think I understand why you did everything else.

I do note that your patch includes the file cbplugin.h with the following change(s):
-#define PLUGIN_SDK_VERSION_MINOR 11
-#define PLUGIN_SDK_VERSION_RELEASE 13
+#define PLUGIN_SDK_VERSION_MINOR 12
+#define PLUGIN_SDK_VERSION_RELEASE 0

I don't know if that will cause you any trouble or not, but going from a 'release' of 13 to a release of '0' seems a bit strange. 

I also don't know what, if any, trouble it may cause me applying your version of the patch to move forward from...?  I expect I will not apply that part unless you advise otherwise.

Also, do you have any guesses as to why my svn diff drops/replaces the entire area of .xrc file even when I used the switches you specified?  (I observe that yours did not.)

I will try to review comments and variable case for needed changes in the next few days.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on October 31, 2010, 10:14:38 am
I do wonder why you changed the formal parameter DebuggerDriver* type to the GDB_driver* type in the step/next classes, when everything else in gdb_commands.h is receiving a parameter type of DebuggerDriver* ?
In order to remove some casts and to document the code by itselt, now someone when reading it will know that it only works with GDB_Driver, not with CDB_Driver.

I think I understand why you did everything else.

I do note that your patch includes the file cbplugin.h with the following change(s):
-#define PLUGIN_SDK_VERSION_MINOR 11
-#define PLUGIN_SDK_VERSION_RELEASE 13
+#define PLUGIN_SDK_VERSION_MINOR 12
+#define PLUGIN_SDK_VERSION_RELEASE 0

I don't know if that will cause you any trouble or not, but going from a 'release' of 13 to a release of '0' seems a bit strange. 
If I understand it correctly the version is something like 1.11.13 and I've modified it to be 1.12.0

to devs: Is RTTI enabled in C::B, can someone use it? On all platforms?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on October 31, 2010, 11:43:04 am
devs should still confirm regarding RTTI enablement...

but if SDK is part of core, I think the following (partial) search results for dynamic_cast<> suggests RTTI is enabled everywhere core builds:

sdk\cbstyledtextctrl.cpp:        if ( EditorBase* pParent = dynamic_cast<EditorBase*>(m_pParent) )
sdk\compilercommandgenerator.cpp:    ProjectBuildTarget* bt = dynamic_cast<ProjectBuildTarget*>(target);
sdk\projectoptionsdlg.cpp:        ProjectBuildTarget* bt = dynamic_cast<ProjectBuildTarget*>(base);
sdk\replacedlg.cpp:        controlToFocus = enabledMultiLine ? dynamic_cast<wxWindow*>(txtFind1) : dynamic_cast<wxWindow*>(cmbFind1);
sdk\replacedlg.cpp:        controlToFocus = enabledMultiLine ? dynamic_cast<wxWindow*>(txtFind2) : dynamic_cast<wxWindow*>(cmbFind2);
sdk\replacedlg.cpp:            controlToFocus = chkMultiLine2->GetValue() ? dynamic_cast<wxWindow*>(txtFind1) : dynamic_cast<wxWindow*>(cmbFind1);sdk\replacedlg.cpp:            controlToFocus = chkMultiLine1->GetValue() ? dynamic_cast<wxWindow*>(txtFind2) : dynamic_cast<wxWindow*>(cmbFind2);
sdk\scrollingdialog.cpp:        // The wxRTTI is wrong for wxNotebook in < 2.8.8 and 2.9, so use dynamic_cast instead
sdk\scrollingdialog.cpp:        wxBookCtrlBase* bookContentWindow = dynamic_cast<wxBookCtrlBase*>(dialog->GetContentWindow());
sdk\templatemanager.cpp:            case totProject: prj = dynamic_cast<cbProject*>(ret); break;
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on November 09, 2010, 09:33:24 pm
anomaly with tooltip/quickwatch hovering over marked text when using gdb

If several lines of text are marked, and the mouse pointer hovered over them, c::b will send the entire marked area to gdb as the argument to gdb's "output" command.  gdb appears to take the first non-blank characters as the argument to output, and then takes any subsequent lines as completely separate attempted commands.

In the situation I observed, the file contained the following lines of text:
VVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVVV
              //SYMBOL_NAME (sym) =
              SYMBOL_LINKAGE_NAME (sym) =
                TDS_SYMBOL_NAME (info, symbol.ts_register.tsr_name);
              SYMBOL_CLASS (sym) = LOC_TYPEDEF;
              SYMBOL_TYPE (sym) =
                tds_get_type (info, symbol.ts_register.tsr_type);
//
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

I had the area marked from point indicated by '^' in "SYMBOL_LINKAGE_NAME (sym) = ^" to the beginninig of the last commented line.

The debugger log shows:
>>>>>>cb_gdb:
> output
                TDS_SYMBOL_NAME (info, symbol.ts_register.tsr_name);
              SYMBOL_CLASS (sym) = LOC_TYPEDEF;
              SYMBOL_TYPE (sym) =
                tds_get_type (info, symbol.ts_register.tsr_type);
Argument required (expression to compute).
Undefined command: "TDS_SYMBOL_NAME".  Try "help".
Undefined command: "SYMBOL_CLASS".  Try "help".
Undefined command: "SYMBOL_TYPE".  Try "help".
Undefined command: "tds_get_type".  Try "help".
>>>>>>cb_gdb:>>>>>>cb_gdb:>>>>>>cb_gdb:>>>>>>cb_gdb:>>>>>>cb_gdb:
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on November 09, 2010, 11:58:49 pm
Confirmed.
There are two possible solutions:
1. Use only the first row from the selected text
2. Display an error

Which do you prefer?

p.s. what happened with the review, I'm not rushing you :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on November 10, 2010, 04:01:02 pm
Confirmed.
There are two possible solutions:
1. Use only the first row from the selected text
2. Display an error

Which do you prefer?
Probably 1.

p.s. what happened with the review, I'm not rushing you :)
Started doing it in patch, botched patch up, so applied original patch but have yet to get back to comparing and applying changes in botched patch to original, and applying in code.

Maybe by this weekend.  (Life has interfered lately.)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on November 13, 2010, 05:21:17 pm
Next disasm .5h. changes iteration (comment changes and variable name change, should be no other code changes from oBFusCATed last mods [.5g. skipped])

Possible submit notes:
1)Check UpdateDisassembly() rather than UpdateBacktrace() for CMD_STEP_INTO_INSTR handling
2)Call NotifyCursorChanged() on CMD_STEP_INTO_INSTR and CMD_STEP_INSTR to update any of various affected windows that may be open
3)Modify disassembly display functionality in effort to
a)reduce number of times (re-)disassembly requested from gdb
b)when possible avoid total redraw of disassembly and
simply reposition "current" instruction gutter indicator
c)correct (one) possible disassembly display failure when program position
moved to lower memory address
4)Modify some of stack frame change response handling to avoid disassembly of area on
autoswitch since may not reflect current program instruction
5)Support "Mixed Mode" disassembly display
6)Add functionality to let user quickly switch "current" instruction position between top/middle/bottom of disassembly window
7)Correct cut-n-paste comment error on GdbCmd_InfoRegisters
*NOTES (with regard to mingw-built GDB 7.2):
A)Response information returned from GDB is sometimes missing current instruction address which results in some (re-)disassembly that might otherwise be avoided.  (I have not found an architecture independent means of determining the current instruction address to work-around these omissions.  GDB's "$pc" changes according to the currently selected stack frame, which may be changed by autoswitch functionality, so cannot be used.)
B)Response information returned from GDB for a mixed mode disassembly sometimes fails to include instructions that are present in the target.  Hence they cannot be found and indicated in the disassembly display.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on November 16, 2010, 01:48:30 pm
Next disasm .5h. changes iteration (comment changes and variable name change, should be no other code changes from oBFusCATed last mods [.5g. skipped])
@oBFusCATed: Do you believe we should apply this now by in the branch and test it through a nightly build?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on November 16, 2010, 01:54:30 pm
I will look at it tonight...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on November 17, 2010, 10:56:59 am
oBFusCATed,

There was also the attach/pause patch, "attachpause.2.patch" (attached in post http://forums.codeblocks.org/index.php/topic,10908.msg91188.html#msg91188)

One of your posts (http://forums.codeblocks.org/index.php/topic,10908.msg91225.html#msg91225) seemed to suggest you had both observed the issue and seen that the patch corrected the problem (but I wasn't certain that's what you were referring to with the "Hm, works on linux" comment).

Is there currently any reason not to apply the "attachpause.2.patch" (from post http://forums.codeblocks.org/index.php/topic,10908.msg91188.html#msg91188)?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on November 17, 2010, 11:08:56 am
... (but I wasn't certain that's what you were referring to with the "Hm, works on linux" comment)....
It means that it works without the patch.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on November 23, 2010, 12:27:12 am
OK, I've finally found some time and here is the modified patch from cbexaminr: http://smrt.is-a-geek.org/codeblocks/patches/dbg/disasm_changes_mine2.patch

What I've done:
1. simplified some comments
2. renamed some variables
3. removed a block #ifdef 0 .... #endif
4. fixed the compilation without pch

If cbexaminr have no objections, the patch could be applied...

Does someone know if it is possible to remove/disable the syntax highlight for particular row?
This feature is needed for the mixed mode disassembly. At the moment all text is highlighted as ASM, which is wrong and ugly.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on November 23, 2010, 05:09:46 pm
If cbexaminr have no objections, the patch could be applied...

One small objection, one additional observation.

objection:
I don't think the logged message about "disasm NO match" should be removed.  I think it will be very useful for people who are wondering why an otherwise unnecessary (re-)disassembly occurred.  

Might want to change the message slightly if you think it can be more informative, but I believe it will serve a useful purpose - it's a warning about an essentially incorrect response.  I think it really shouldn't ever occur, if GDB were always returning the address information in responses.

But, if you want to answer those questions from users, I guess that's OK with me... :)

observation:
disassemblydlg.h seems to have acquired a
#include <vector>
the purpose of which I fail to see...

Sorry I missed those other variables you camel-cased.  I really did look for them.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on November 23, 2010, 06:34:11 pm
observation:
disassemblydlg.h seems to have acquired a
#include <vector>
the purpose of which I fail to see...
4. fixed the compilation without pch (precompiled header)

objection:
I don't think the logged message about "disasm NO match" should be removed.  I think it will be very useful for people who are wondering why an otherwise unnecessary (re-)disassembly occurred. 
Hm, this message looks like it is meant for debugging, not for the users, they won't understand it.
And if I understand the code correctly, the disassembly will be generated, so this is not an error?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on November 23, 2010, 08:46:34 pm
its an error in that the disassembly should (usually) _not_ have to be re-generated.  That code path (I claim) should not have to exist at all if GDB always returned the correct information.

Maybe no one will complain... the code will certainly work without it, its just that when that path is taken you may be re-disassembling the same area repeatedly, which I anticipate somebody will complain about eventually, and it makes it easy to see why the re-disassembly occurred - it marks a path indicating "bad gdb output", so maybe the msg could be "disassembly, bad gdb output".  Since I don't know what triggers the instance I've seen, nor how often it or other unrecognized output may occur, tough to say just how often it will occur.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on November 23, 2010, 09:36:07 pm
This info is needed for the developer of the plugin and it is there, if someone tries to understand what it is happening he/she will have a clue.
Users don't care for the implementation details...

If you needed this warning message as a user, I'm OK to re-add it, if you needed it only to debug the plugin, I'm against it :)

Lets minimize further talking and get this patch in the tree, OK?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on November 23, 2010, 09:51:46 pm
Ok.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on November 25, 2010, 08:40:59 pm
BTW, I've one problem with the just committed patch:

When the disassembly is in mixed mode, both c/c++ and asm lines are coloured as asm lines.
Does someone knows if it is possible to disabled the syntax highlight for single line or a block of text?

I've looked at the code, but I couldn't find anything that would do the job.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on November 25, 2010, 08:51:57 pm
Next patch: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0017.7.patch  (improved version of http://forums.codeblocks.org/index.php/topic,10908.msg89496.html#msg89496 )

1. Added GetIsRunning method to ProjectManager, it is used to query the plugin that is running the project (running the application, debugging the application, etc)
2. Added SetIsRunning method to ProjectManager, it is used to set the plugin that is running/executing the project, it is set only if the GetIsRunning returns NULL
3. Modified the Compiler plugin to use the new methods (set and reset correctly the running flag, modified the toolbar/menu updateui functions)
4. Modified the Debugger plugin to use the new methods (set and reset correctly the running flag, modified the toolbar/menu updateui functions)
5. Fixed all (almost), bugs I've encountered since v17.3

I think this patch could be applied now, Morten?
Also what about another nightly build, so the disassembly changes and the changes in v17.7 could be tested in the wild? :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on November 25, 2010, 08:54:15 pm
...I got another 2 issues:
1.) I am not sure if this is related: But after applying the patch C::B does not startup anymore and I receive an error that the wxScintilla window could not be created in the constructor, in this line:
Code
    m_pCode = new wxScintilla(this, wxID_ANY);
...which goes back into the disassembly window (which was modified). I am still investigating though as in parallel I modified scintilla, too... unfortunately.
2.) From the logs I see a lot NULL pointer issues. meaning crash candidates, e.g.:
Code
    m_MixedModeCB = (wxCheckBox*)FindWindow(XRCID("chkMode"));
    m_MixedModeCB->SetValue(Manager::Get()->GetDebuggerManager()->IsDisassemblyMixedMode());
...or here:
Code
    DebuggerManager &manager = *Manager::Get()->GetDebuggerManager();
    bool newMode = !manager.IsDisassemblyMixedMode();
Please always make sure you verify pointers. The only exception might be singleton classes, but even then you must be careful if the app shuts down. The latter is strange anyways, why don't you operate with pointers here? This is the only place I know where a singleton class is used by reference. IMHO this is dangerous and violates somehow the concept of a singleton.

Concenring functionality: Well... I'll try to get it up and running... :lol:
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on November 25, 2010, 10:30:47 pm
...I got another 2 issues:
1.) I am not sure if this is related: But after applying the patch C::B does not startup anymore and I receive an error that the wxScintilla window could not be created in the constructor, in this line:
Code
    m_pCode = new wxScintilla(this, wxID_ANY);
...which goes back into the disassembly window (which was modified). I am still investigating though as in parallel I modified scintilla, too... unfortunately.
Running HEAD of the branch and I can start and use C::B, even the disassembly window works.

2.) From the logs I see a lot NULL pointer issues. meaning crash candidates, e.g.:
Code
    m_MixedModeCB = (wxCheckBox*)FindWindow(XRCID("chkMode"));
    m_MixedModeCB->SetValue(Manager::Get()->GetDebuggerManager()->IsDisassemblyMixedMode());
...or here:
Code
    DebuggerManager &manager = *Manager::Get()->GetDebuggerManager();
    bool newMode = !manager.IsDisassemblyMixedMode();
Please always make sure you verify pointers. The only exception might be singleton classes, but even then you must be careful if the app shuts down. The latter is strange anyways, why don't you operate with pointers here? This is the only place I know where a singleton class is used by reference. IMHO this is dangerous and violates somehow the concept of a singleton.
Which logs?
Morten, you can find code like "SomeManager *manager =  Manager::Get()->GetSomeManager();" all over C::B's sources and very few times the pointer is checked.
Also the "SomeManager *manager =  Manager::Get()->GetSomeManager();" and "SomeManager &manager =  *Manager::Get()->GetSomeManager();" is pretty much the same.
If you don't like it, you can rewrite it the style you prefer :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on November 26, 2010, 06:36:06 am
Running HEAD of the branch and I can start and use C::B, even the disassembly window works.
Well - the strange thing is: If I disable the debugger plugin all works fine again. All editors (based on wxScintilla) are able to create their windows, just not the disassembly window. This error remains which makes the debugger plugin unusable for me atm. :-(

Which logs?
The SVN diff I meant, not log.

Morten, you can find code like "SomeManager *manager =  Manager::Get()->GetSomeManager();" all over C::B's sources and very few times the pointer is checked.
That is exactly what I meant! This version is the standard and it's OK to use this even without pointer check (as I've written:)
The only exception might be singleton classes, but even then you must be careful if the app shuts down.
All I am asking for is to use the same style everywhere, so use the managers as pointers (SomeManager *manager =...) and not as reference (SomeManager &manager =...), that's it.
If you don't like it, you can rewrite it the style you prefer :)
I can do so. But please keep the "correct" style in mind in the future just for consistency (not functionality).
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on November 26, 2010, 09:59:43 am
Running HEAD of the branch and I can start and use C::B, even the disassembly window works.
Well - the strange thing is: If I disable the debugger plugin all works fine again. All editors (based on wxScintilla) are able to create their windows, just not the disassembly window. This error remains which makes the debugger plugin unusable for me atm. :-(
Stupid questions: have you tried full rebuild or checkout of a clean version in another directory?
Anyone else having the same problems?

I can do so. But please keep the "correct" style in mind in the future just for consistency (not functionality).
Okay :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on November 26, 2010, 02:40:08 pm
Stupid questions: have you tried full rebuild or checkout of a clean version in another directory?
Yes, several times, different machines. On all machines I have the same effect (they all have a common OS though...).

Anyone else having the same problems?
I would be interested in this very much, too. I'll try to compile the debugger version only (thus not having applied my local modification of wxScintilla). Still I believe that is not the reason as wxScintilla works well in all other editors / plugins (e.g. cbEditor, the preview in ThreadSearch and alike...).

Maybe Lieven can give some hints when compiling another nightly of the branch... at any time.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: killerbot on November 26, 2010, 03:57:44 pm
I had plan to build a new version somewhere either Sunday morning, or Sunday evening.

Since trunk has been merged to debugger_branch, it is a good time indeed ...


PS : something that occurs to me from time to time on trunk while debugging :
CB stops the debug sessions (or the debug sessions was stopped because the program ran till completion), nevertheless CB keeps showing that the debugger is still running (and it is actually, asking through CB [toolbar- button or menu] to stop doesn't help). Only solution is to kill gdb, and then we are back in bizznizz.
Oh yeah : on linux.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on November 26, 2010, 04:20:36 pm
killerbot:
Can you try the branch to see if this behavior happens there, too?
I think, I've seen this in the past with trunk's version, the branch's version doesn't have this problem or I've not seen it lately (unfortunately I'm not using C::B much).
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on November 26, 2010, 04:32:44 pm
I had plan to build a new version somewhere either Sunday morning, or Sunday evening.

Since trunk has been merged to debugger_branch, it is a good time indeed ...


PS : something that occurs to me from time to time on trunk while debugging :
CB stops the debug sessions (or the debug sessions was stopped because the program ran till completion), nevertheless CB keeps showing that the debugger is still running (and it is actually, asking through CB [toolbar- button or menu] to stop doesn't help). Only solution is to kill gdb, and then we are back in bizznizz.
Oh yeah : on linux.
The same happens here from time to time,too.

Newest dbg-branch works, without th issue described by MortenMacFly.

Another issue, to see the checkbox and the buttons of the disassembly dialog, I have to undock and resize it.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on November 26, 2010, 05:28:48 pm
The same happens here from time to time,too.
In dbg-branch or in trunk?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on November 26, 2010, 05:32:24 pm
The same happens here from time to time,too.
In dbg-branch or in trunk?
In trunk, but I fo not use the debugger-branch very often, so it might also happen here.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on November 27, 2010, 12:28:50 am
Another issue, to see the checkbox and the buttons of the disassembly dialog, I have to undock and resize it.

I fixed this issue in trunk (svn r6862) and debugger-branch (svn r6863).

If wxScinitll is created wit wxDefaultSize, the MinSize was set to large, so that parts of the dialog have been hidden in any useful size (seems to happen only with wxGTK not wxMSW), setting it after creation seems to have no effect.
Setting the initial size to wxSize(1,1) fixes the issue and seems to be without side-efects (at least I did not find any on linux and windows).
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on November 28, 2010, 08:22:47 pm
Anyone else having the same problems?
I would be interested in this very much, too. I'll try to compile the debugger version only (thus not having applied my local modification of wxScintilla). Still I believe that is not the reason as wxScintilla works well in all other editors / plugins (e.g. cbEditor, the preview in ThreadSearch and alike...).
Argh! Forget about it, I finally found the reason: When merging the disassembly XRC I forgot a closing </object> tag. Thus this file was invalid and the error was raised. I was looking in cpp source code though. Nevermind - stupid error message for what was actually going wrong. :?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on December 06, 2010, 12:11:10 am
Next patch: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0018.1.patch

Fixed problems:
1. Stopping (Break command) doesn't work when attach to process is used on windows.
   The problem was happening because the child pid wasn't detected when attaching to process.
   I've added another regex and now the child pid should be detected correctly
2. When stopping the debugger, the kill and quit commands weren't executed.
   The reason is that m_pProcess->CloseOutput() is called too early.

cbexaminr, thanks for the report, but your patch was a workaround, I've fixed (hopefully) the real problem :)

Please test and report any problems, I hope to test it on linux in the next couple of days
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: xhpohanka on December 08, 2010, 08:03:41 am
Hi,
I wanted to try your version of debugger, but I was not successful in applying the posted patch (dbg_refactor0018.1.patch). From it's code I thought it has to be applied to the svn version 6872.

Code
$ patch -p0 < dbg_refactor0018.1.patch
(Stripping trailing CRs from patch.)
patching file src/plugins/debuggergdb/debuggergdb.cpp
Hunk #1 FAILED at 1640.
1 out of 1 hunk FAILED -- saving rejects to file src/plugins/debuggergdb/debuggergdb.cpp.rej
(Stripping trailing CRs from patch.)
patching file src/plugins/debuggergdb/gdb_driver.h
Hunk #1 succeeded at 115 (offset -10 lines).
(Stripping trailing CRs from patch.)
patching file src/plugins/debuggergdb/gdb_driver.cpp
Hunk #1 succeeded at 69 (offset -5 lines).
Hunk #2 succeeded at 83 (offset -5 lines).
Hunk #3 succeeded at 483 (offset -19 lines).
Hunk #4 succeeded at 540 with fuzz 1 (offset -21 lines).
Hunk #5 succeeded at 552 with fuzz 2 (offset -28 lines).
Hunk #6 FAILED at 768.
patch unexpectedly ends in middle of line
Hunk #7 succeeded at 761 with fuzz 1 (offset -35 lines).
1 out of 7 hunks FAILED -- saving rejects to file src/plugins/debuggergdb/gdb_driver.cpp.rej

I hope that I'm not missing something obvious...

regards
Jan
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on December 08, 2010, 08:06:47 am
Hi,
I wanted to try your version of debugger, but I was not successful in applying the posted patch (dbg_refactor0018.1.patch). From it's code I thought it has to be applied to the svn version 6872.

Code
$ patch -p0 < dbg_refactor0018.1.patch
(Stripping trailing CRs from patch.)
patching file src/plugins/debuggergdb/debuggergdb.cpp
Hunk #1 FAILED at 1640.
1 out of 1 hunk FAILED -- saving rejects to file src/plugins/debuggergdb/debuggergdb.cpp.rej
(Stripping trailing CRs from patch.)
patching file src/plugins/debuggergdb/gdb_driver.h
Hunk #1 succeeded at 115 (offset -10 lines).
(Stripping trailing CRs from patch.)
patching file src/plugins/debuggergdb/gdb_driver.cpp
Hunk #1 succeeded at 69 (offset -5 lines).
Hunk #2 succeeded at 83 (offset -5 lines).
Hunk #3 succeeded at 483 (offset -19 lines).
Hunk #4 succeeded at 540 with fuzz 1 (offset -21 lines).
Hunk #5 succeeded at 552 with fuzz 2 (offset -28 lines).
Hunk #6 FAILED at 768.
patch unexpectedly ends in middle of line
Hunk #7 succeeded at 761 with fuzz 1 (offset -35 lines).
1 out of 7 hunks FAILED -- saving rejects to file src/plugins/debuggergdb/gdb_driver.cpp.rej

I hope that I'm not missing something obvious...

regards
Jan

did you use the debugger_branch?? this patch is already in the branch

see the log: rev 6873

Quote

* debugger_branch: applied patch dbg_refactor0018.1:
- stopping (break command) doesn't work when attach to process is used on windows
- when stopping the debugger, the kill and quit commands weren't executed

-------------------------------
M : /branches/wxpropgrid_debugger/src/plugins/debuggergdb/debuggergdb.cpp 
M : /branches/wxpropgrid_debugger/src/plugins/debuggergdb/gdb_driver.cpp 
M : /branches/wxpropgrid_debugger/src/plugins/debuggergdb/gdb_driver.h 
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: xhpohanka on December 08, 2010, 08:19:04 am

did you use the debugger_branch?? this patch is already in the branch


You are right, my fault. Thank you...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on December 18, 2010, 04:18:30 pm
Next patch: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0019.0.patch

Fixes:
1. Step into executes start instead of run (regression caused by the patch 0017.x)
2. Console window is hidden when remote debugging on windows (thanks Pecan)
3. The string used in evaluate tooltip is trimmed and only the first line is used
4. Fixed some parsing issues related to the '<repeats X times>'
5. Fixed a spelling error in the name of MainFrame::OnGetActiveLogWindow
6. Added more tests to the test project for the debugger

Killerbot: can you build a nightly, so we can test this last changes and hopefully get this code in trunk?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: killerbot on December 18, 2010, 04:40:47 pm
oh yes, I am just waiting for a merge of the trunk to debugger branch, we want some goodies from that one first ;-)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on December 18, 2010, 05:07:22 pm
oh yes, I am just waiting for a merge of the trunk to debugger branch, we want some goodies from that one first ;-)
Go ahead! It's all done. ;-)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: killerbot on December 18, 2010, 06:21:14 pm
starting to build, release probably tomorrow morning
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 16, 2011, 02:28:41 pm
Next patch: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0019.1.patch

Changes:
1. The Watches are refreshed, when the watches dialog is shown and the debugger is running (fixes bug reported by killerbot)
2. Added a virtual method, so a debugger plugin can modify the context menu in the watches dialog (the SDK API is broken)
3. Used the new feature SDK to reimplement "dereference pointer" feature
4. Removed some unused member variables in the class DebuggerGDB

Test please :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: etheranger on January 21, 2011, 02:54:42 pm
Someone suggested I port my CDB fixes to the branch, so here 'tis (against 6930):

https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=3122&group_id=5358 (https://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=3122&group_id=5358)
Changes:
+ Grab the PID at launch so that process break / killing works - this allows setting breakpoints while running
+ NotifyDebuggeeContinued on Continue so that the cursor doesn't disappear forever after setting breakpoints while running
+ Slightly improve recognising breakpoint & assert hits
+ Added workaround to correctly set working dir (can still be disabled by #undefining ENABLE_WORKINGDIR_WORKAROUND.

I'd appreciate some feedback on the last point at http://forums.codeblocks.org/index.php/topic,14085.0.html (http://forums.codeblocks.org/index.php/topic,14085.0.html) if you have an opinion :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 21, 2011, 03:25:35 pm
Thank you, I was that someone.

I'll look at it tonight or in the weekend...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 21, 2011, 03:54:11 pm
I'll look at it tonight or in the weekend...
Ok - so you will take care and tell me if it's working properly and is applied in the branch so I can close the ticket, please? :-)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 21, 2011, 04:39:23 pm
Yes, can you test it, too?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 21, 2011, 04:43:24 pm
Yes, can you test it, too?
I must admit that I never worked a lot with CDB, but I can try.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 26, 2011, 01:36:31 am
+ Added workaround to correctly set working dir (can still be disabled by #undefining ENABLE_WORKINGDIR_WORKAROUND.

Have you tried to pass the .create command in the -c command line option?

Quote
-c "command"
Specifies the initial debugger command to run at start-up. This command must be surrounded with quotation marks. Multiple commands can be separated with semicolons. (If you have a long command list, it may be easier to put them in a script and then use the -c option with the $<, $><, $><, $$>< (Run Script File) command.)

Hm, it seems that the breakpoints are a bit broken. The current position marker is displayed 1 line after the breakpoint.
Etheranger, Morten do you see this problem, too?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: etheranger on January 26, 2011, 05:38:19 am
+ Added workaround to correctly set working dir (can still be disabled by #undefining ENABLE_WORKINGDIR_WORKAROUND.

Have you tried to pass the .create command in the -c command line option?

Yeah, even with an opening command with -c, CDB still won't run unless you pass in a .exe on the command line (cdb.exe -c ".create myprog.exe" isn't a valid usage). I tried throwing a -c ".createdir workingdir" in, but it gets executed after the debuggee has already been launched :(
If there was some kind of standard dummy executable we could use instead of the process I'm killing (like `true` in gnu) that would be nice, but as far as I can see the only .exe we can be sure of existing is the debuggee.

Hm, it seems that the breakpoints are a bit broken. The current position marker is displayed 1 line after the breakpoint.
Etheranger, Morten do you see this problem, too?
As far as I can see, it seems to be correctly stopping directly on the breakpoint. Is it possible yours is on a line that's being optimised out / otherwise non-executable?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 26, 2011, 07:01:52 am
OK, I'll try some things and if they don't work, the workaround will stay.

breakpoints:
The executable is build with /Zi /Od (or /0d) /MDd and it stops on the next line.
Here is the version of the debugger "Microsoft (R) Windows Debugger Version 6.11.0001.404 X86".
 I'm using the latest nightly, without your changes.

Code
Command-line: c:\Program Files\Debugging Tools for Windows (x86)\cdb.exe -G -lines -y C:/dev/projects/tests/cdb_test/; -srcpath C:/dev/projects/tests/cdb_test/; bin/debug/cdb_test.exe
Working dir : C:\dev\projects\tests\cdb_test\
> bc *
Microsoft (R) Windows Debugger Version 6.11.0001.404 X86
Copyright (c) Microsoft Corporation. All rights reserved.
CommandLine: bin/debug/cdb_test.exe
Symbol search path is: C:/dev/projects/tests/cdb_test/
Executable search path is:
ModLoad: 00400000 0040f000   cdb_test.exe
ModLoad: 7c900000 7c9b2000   ntdll.dll
ModLoad: 7c800000 7c8f6000   C:\WINDOWS\system32\kernel32.dll
ModLoad: 10480000 10557000   C:\WINDOWS\WinSxS\x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_f863c71f\MSVCP90D.dll
ModLoad: 10200000 10323000   C:\WINDOWS\WinSxS\x86_Microsoft.VC90.DebugCRT_1fc8b3b9a1e18e3b_9.0.30729.1_x-ww_f863c71f\MSVCR90D.dll
(300.115c): Break instruction exception - code 80000003 (first chance)
eax=00251eb4 ebx=7ffdb000 ecx=00000003 edx=00000008 esi=00251f48 edi=00251eb4
eip=7c90120e esp=0012fb20 ebp=0012fc94 iopl=0         nv up ei pl nz na po nc
cs=001b  ss=0023  ds=0023  es=0023  fs=003b  gs=0000             efl=00000202
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for ntdll.dll -
ntdll!DbgBreakPoint:
7c90120e cc              int     3
0:000> 0:000>
> bu1 `C:/dev/projects/tests/cdb_test/main.cpp:40`
*** WARNING: Unable to verify checksum for cdb_test.exe
0:000>
> l+t
Source options are 1:
     1/t - Step/trace by source line
0:000>
> l+s
Source options are 5:
     1/t - Step/trace by source line
     4/s - List source code at prompt
0:000>
> l+o
Source options are d:
     1/t - Step/trace by source line
     4/s - List source code at prompt
     8/o - Only show source code at prompt
0:000>
> g
Breakpoint 1 hit
>   40:     printf("curr dir: %s\n", curr_dir);
0:000>
> k n
 # ChildEBP RetAddr 
00 0012ff68 00405058 cdb_test!main+0x45 [c:\dev\projects\tests\cdb_test\main.cpp @ 40]
01 0012ffb8 00404e9f cdb_test!__tmainCRTStartup+0x1a8 [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 586]
*** ERROR: Symbol file could not be found.  Defaulted to export symbols for C:\WINDOWS\system32\kernel32.dll -
02 0012ffc0 7c817077 cdb_test!mainCRTStartup+0xf [f:\dd\vctools\crt_bld\self_x86\crt\src\crtexe.c @ 403]
WARNING: Stack unwind information not available. Following frames may be wrong.
03 0012fff0 00000000 kernel32!RegisterWaitForInputIdle+0x49
0:000>
> q
quit:

As you can see the debugger returned the correct line, but in C::B it is +1.
Code
Breakpoint 1 hit
>   40:     printf("curr dir: %s\n", curr_dir);
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 29, 2011, 07:51:44 pm
OK, I've done some modifications to the etheranger's patch: http://smrt.is-a-geek.org/codeblocks/patches/dbg/cdb_fixed.patch

1. I've removed the workaround, instead of the killing, CDB is executed at the working directory.
2. CDB launches separate cmd window for console applications
3. Done some refactoring here and there :)

Please test and report if there are any problems...


p.s. etheranger you've fixed the breakpoint+1 problem :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: etheranger on February 03, 2011, 02:39:51 am
That seems to all be working fine for me so far.

I'd tried something similar with the working dir earlier, but I missed making the debuggee path absolute, so codeblocks.cbp stopped running for me :P
Obviously you've fixed that, and I take it the algorithm for populating source directories to pass to the debugger always returns an absolute path.

Nice!
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 03, 2011, 09:14:16 am
Morten: go go go with the commit :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on February 03, 2011, 08:49:02 pm
Morten: go go go with the commit :)
...done. Good work!
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 03, 2011, 08:56:12 pm
Thanks Morten, you can close the patches in Berlios, if you've not done so already  8)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: dmoore on February 03, 2011, 11:19:28 pm
Obfuscated: Any chance you can help me use your Debugger API to write a plugin for Python debugging? (I have some very old code -- a massive hack -- where I tried to do this but your work would make it much simpler and better integrated). And by "help", I mean tell me what to look at to get started, tell me what I'm doing wrong when I hit a wall etc. You don't have to provide any code.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 04, 2011, 01:52:56 am
Yes, I can and I will be glad :)

The two things you can look at are the debugger plugin in the cb's svn and my try at gdb/mi plugin.
My plugin can be accessed with svn at svn://smrt.is-a-geek.org/cb_gdb_mi/debbugger_gdbmi (at the moment I think it fails to compile).

The basic idea is: you make a plugin, derive from cbDebuggerPlugin, then you implement all the virtual methods :)

Take a look at both plugins and if you have questions ask :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: dmoore on February 05, 2011, 04:03:01 am
I spent an hour or so today looking through the code. I think I have a rough understanding of the new features. I have a few basic questions.

1. Just to be sure, is the latest SDK code here:

svn checkout http://svn.berlios.de/svnroot/repos/codeblocks/branches/wxpropgrid_debugger

To save me some reading/testing:

2. How does the handling of multiple debuggers work? Do they all share the same ui elements? What happens when a user switches between debuggers using the active debugger menu option? (e.g. what happens to the ui elements such as the watch, stack etc?) If plugin 1 is already debugging, can I switch to plugin2 and start a new debugging session and keep the session in plugin1 active? (And will the framework update the ui appropriately when I switch between them?)

3. For a python application, it probably makes the most sense to start debugging the active file in the editor (rather than the active target). Is that going to be a problem?

4. What is the purpose of OnAttachReal/OnReleaseReal? I hope we never see OnAttachReallyReallyReal :)

Thanks for the good work on this, oBFusCATed.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 05, 2011, 07:55:46 am
1. Yes, this is it
2. They share the UI and there is Manager::Get()->GetDebuggerManager()->GetActiveDebugger(). You can change the active debugger with Debug->Active debugger. I think the active debugger can't be changed during the debug session. This should change in the future, but I've not thought about it, much. Probably it should be possible to debug with a combination of plugins  -> 'C++ + python' or 'c++ + lua' (I use this combination, but no lua debugger at the moment :( )
3. No problem, there is a Start method or something like that. There you can do whatever you like or is appropriate.
4. There is some common setup happening in OnAttach/OnRelease, then they call OnAttachReal/OnReleaseReal. If you can think of better names I can change them no problem.
    And I hope we won't add any more methods with Reals at the end :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on February 05, 2011, 10:54:37 am
4. There is some common setup happening in OnAttach/OnRelease, then they call OnAttachReal/OnReleaseReal. If you can think of better names I can change them no problem.
    And I hope we won't add any more methods with Reals at the end :)
How about renaming the first to "OnAttachBase" and the speci alised methods to "OnAttach"?!
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on February 05, 2011, 11:36:54 am
4. There is some common setup happening in OnAttach/OnRelease, then they call OnAttachReal/OnReleaseReal. If you can think of better names I can change them no problem.
    And I hope we won't add any more methods with Reals at the end :)
How about renaming the first to "OnAttachBase" and the speci alised methods to "OnAttach"?!
Or OnAttach and DoAttach, as we do it on other places.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 05, 2011, 06:49:56 pm
+1 for Jens' suggestion
-1 to Morten's, because OnAttach is declared in cbPlugin, so I can't change its name.

Another options is
Code
MyPlugins::OnAttach(...)
{
    cbDebugger::OnAttach(...);
    ....
}

But I don't like it too much.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: dmoore on February 06, 2011, 09:16:15 am
1. Yes, this is it
2. They share the UI and there is Manager::Get()->GetDebuggerManager()->GetActiveDebugger(). You can change the active debugger with Debug->Active debugger. I think the active debugger can't be changed during the debug session. This should change in the future, but I've not thought about it, much. Probably it should be possible to debug with a combination of plugins  -> 'C++ + python' or 'c++ + lua' (I use this combination, but no lua debugger at the moment :( )
3. No problem, there is a Start method or something like that. There you can do whatever you like or is appropriate.
4. There is some common setup happening in OnAttach/OnRelease, then they call OnAttachReal/OnReleaseReal. If you can think of better names I can change them no problem.
    And I hope we won't add any more methods with Reals at the end :)

Based on this, I should be able to simply reuse large chunks of my old Python Debugger Plugin then gradually refactor it. I'll hopefully report back next week...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on February 07, 2011, 04:14:10 am
Proposed feature patch

Support invocation of (gdb) debugger for a specific executable without any project/workspace being loaded

patch adds menu item to Debug menu (Debug external process) and adds code to support that item for gdb configured debugger

developed/used with personally built mingw gdb 7.2

Caveats:
1)Interface is multiple gettext boxes, eventually should prob. be a dialogue (but I'd like this basic functionality now)
2)Needs to support remote debugging as well (but that requires grok'ing additional code that currently _does_ seem to be very intertwined with a project's existence/presence, and is additional work beyond this basic functionality)
3)Some changes have been made to the cdb debugger side, but I have not tried it, and do not know whether those changes are sufficient.
4)tested on windows only, but expect it to work on *nix as well.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on February 07, 2011, 04:24:26 am
Does any interest (apart from myself) remain in the experimental scrolling 'quickwatch' tooltip variable view?  

(Originally worked on some in separate thread, and last [I think] mentioned in this thread, with patch, but seemingly either ignored, or overlooked...)

The last version posted only displayed outermost items, requiring 'open'ing of sub-layers for conglomerate/list items...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: dmoore on February 07, 2011, 05:39:53 am
Does any interest (apart from myself) remain in the experimental scrolling 'quickwatch' tooltip variable view?

Sounds interesting to me.

Obfuscated: I put together a stub Debugger plugin, but having a hard time figuring out how to get my plugin to show up in Debug->ActiveDebuggers menu. I have put this in my plugins OnAtttachReal:

Code
    DebuggerManager &dbg_manager = *Manager::Get()->GetDebuggerManager();
    dbg_manager.RegisterDebugger(this, _T("testplugin"));

Most of the virtual method implementations are empty stubs at this point. What else to I need to add before the plugin shows up in the ActiveDebuggers submenu?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: dmoore on February 07, 2011, 06:06:47 am
Never mind: my plugin had implementations of OnAttach and OnRelease. I removed those and did what was necessary in  OnAttachReal/OnReleaseReal (something to be wary of...)

Next issue: When my plugin is made the active debugger, how do I tell the debugger UI to wake up? (i.e. most of the Debug Menu is greyed out at start up)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 07, 2011, 09:57:49 am
dmoore:
You should have "debug->start", "debug->run to cursor" and "debug->step into" active. Is this the case?
If it is not, look in the debugger_menu.cpp, there are two UpdateUI/OnUpdateUI methods.

cbexaminr:
1. Why do you need such feature? C::B is not intended as a gdb/cdb-only wrapper. It is an IDE with debugging support.
2. I've added the tooltips to my TODO, but I've postponed looking at them several times.
Title: (accident - delete me - after moving oBFus post per request)
Post by: cbexaminr on February 07, 2011, 10:52:56 am
[deleted - misplaced due to timeouts]
[oBFus post and mine 'delete' request changes crossed on the wires]

[Readded content to be in correct order (Jens) :]

1. Why do you need such feature? C::B is not intended as a gdb/cdb-only wrapper. It is an IDE with debugging support.

personal need - I am debugging items that cannot currently be built with C::B (borland/codegear/EMBT VCL-based applications), and C::B and GDB are the tools that I have currently chosen to invest in to make this possible (vendor tool usage has "issues".)

general justification - if C::B is the tool one has at hand, and, is familiar with, one should not be be forced to obtain-or-create/install/learn a different tool, when there is no particularly rational reason C::B can't provide that functionality.

question - What _is_ an IntegratedDevelopmentEnvironment?

answer - A set of tools that work well together to support development of applications.  In order of anticipated common usage, most to least, that would likely generally include editor/build support/debugger/analysis-documentation tools.

observation - The organization of an IDE should not arbitrarily impose any requirement that tools which (can) work well alone, be unnecessarily structured to require working only with each other, when such "separate" usage architecture does not impose any significant penalty on that combined entity nor the effort involved in implementing it.  (If you disagree with this, then perhaps you should consider disabling the ability to use the editor without having a project/workspace open :) .)  If, the continued separate usage architecture of such tools imposes some significant penalty/requirement that no-one is willing to pay, then perhaps such implementation might be best avoided - but, I have already made the initial investment here, and I don't think the maintenance requirements will be significant.

I do not seek a gdb/cdb-wrapper only :) - I seek a tool that will serve me reasonably in various situations.
Title: Re: re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 07, 2011, 11:08:22 am
personal need - I am debugging items that cannot currently be built with C::B (borland/codegear/EMBT VCL-based applications), and C::B and GDB are the tools that I have currently chosen to invest in to make this possible (vendor tool usage has "issues".)
You can use a dummy project for this or a Makefile project...

Quote
general justification - if C::B is the tool one has at hand, and, is familiar with, one should not be be forced to obtain-or-create/install/learn a different tool, when there is no particularly rational reason C::B can't provide that functionality.
...
observation - The organization of an IDE should not arbitrarily impose any requirement that tools which (can) work well alone, be unnecessarily structured to require working only with each other, when such "separate" usage architecture does not impose any significant penalty on that combined entity nor the effort involved in implementing it.  (If you disagree with this, then perhaps you should consider disabling the ability to use the editor without having a project/workspace open :) .)  If, the continued separate usage architecture of such tools imposes some significant penalty/requirement that no-one is willing to pay, then perhaps such implementation might be best avoided - but, I have already made the initial investment here, and I don't think the maintenance requirements will be significant.
What about integrating your cooker in C::B?  :P
An IDE imposes some style of work...

I'll look at the patch, but there is a chance that it won't be applied/approved...

Quote
I do not seek a gdb/cdb-wrapper only :) - I seek a tool that will serve me reasonably in various situations.
Combining several tools sometimes is way powerful then using single tool for everything.

p.s. can someone move these two posts to the thread?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on February 07, 2011, 11:18:49 am
[content removed, see two posts above (Jens)]
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: dmoore on February 07, 2011, 03:40:16 pm
dmoore:
You should have "debug->start", "debug->run to cursor" and "debug->step into" active. Is this the case?

After playing around some more, yes, but only when a project is active. I often edit python scripts in C::B without using projects (hence the existence of File Manager and Tools+ plugins). Is there an easy way to handle this case? (I'd actually like to offer the user the option to debug the active editor or the active target (if the target is a python file). So maybe I just need to add another menu option?)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 07, 2011, 03:54:01 pm
Can you try to return true in IsAttachedToProcess(), for now, later we could fix it correctly.

Please write down every problem you encounter, then give me the list, so I can try to fix them.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: dmoore on February 07, 2011, 04:03:44 pm
Can you try to return true in IsAttachedToProcess(), for now, later we could fix it correctly.

Please write down every problem you encounter, then give me the list, so I can try to fix them.

Yes, I'll try that. I'll also start regularly uploading the python plugin code to my berlios project svn repository so that you can more easily see what I'm talking about (and, if I have time, document my process of writing the plugin a little for future debugger plugin devs).
Title: Re: re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on February 07, 2011, 06:19:44 pm
What about integrating your cooker in C::B?  :P
I would think integrating PLC programming tools would be much more useful for that than my actual cooker.

An IDE imposes some style of work...
Lucky for me this is really no different in nature than Attach to process, so its in line with the style of work already supported by C::B (as it allows attaching to any arbitrary process, and does not verify that its one generated by a target of any project that may be open, and does not require any project to be open at all, with the menu option being available without a project.)

I'll look at the patch, but there is a chance that it won't be applied/approved...
Any guestimates as to when you will present your opinion on acceptance/denial?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 07, 2011, 06:47:45 pm
Soon  :P  :lol:
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 08, 2011, 12:51:44 am
cbexaminr: You're adding gdb specific stuff in the SDK, this is not right, so you get no as an answer.
  Move the GUI inside the gdb plugin and please don't add another Is*Something that should be checked in the UpdateUI methods.
  They are pretty messed, so adding more stuff there makes the messier.

BTW: I plan to improve the Settings->Compiler & Debugger -> Debugger.
My current plan is to make it possible to have different debuggers with different settings.
For example: gdb6.8, gdb7.2, gdb for arm, cdb, etc.
And then in the compilers settings you'll have a wxChoice control, so you can choose one of the debuggers.
There will be a default debugger (I've not thought about it much). And if there is not project opened we could
interpret Debug->Start as the StartExternalProcess in your patch, but changes should be handled internally (inside the specific plugin).


p.s. there is wxEmptyString, use it instead of _(""), also use _("...") only when you want the string to be translatable, else use wxT("...") or _T("...")
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on February 08, 2011, 05:15:46 am
cbexaminr: You're adding gdb specific stuff in the SDK, <snip>
I don't think so.  I assume you're referring to the...
  Move the GUI inside the gdb plugin
GUI, which should be serving both GDB and CDB, but I will verify. (I was hoping someone else might verify that path since I'm not set up with CDB available currently.)
and please don't add another Is*Something that should be checked in the UpdateUI methods.
  They are pretty messed, so adding more stuff there makes the messier.
What then, is the currently available alternative, to determine that the debugging toolbar icons and menu options should be enabled/available?  (The IsExternalProcess() was just following the pattern established by the previously existing IsAttachedToProcess() functionality.)  I would have guessed the presence of m_activeDebugger to be enough, but the previously existing code in DebuggerMenu suggests not...???

BTW: I plan to improve the Settings->Compiler & Debugger -> Debugger.
My current plan is to make it possible to have different debuggers with different settings.
For example: gdb6.8, gdb7.2, gdb for arm, cdb, etc.
And then in the compilers settings you'll have a wxChoice control, so you can choose one of the debuggers.
There will be a default debugger (I've not thought about it much). And if there is not project opened we could
interpret Debug->Start as the StartExternalProcess in your patch, but changes should be handled internally (inside the specific plugin).
Neither of Debug/Start-Continue menu option nor related toolbar icon are currently enabled in that circumstance.  How will you deal with that?
p.s. there is wxEmptyString, use it instead of _(""), also use _("...") only when you want the string to be translatable, else use wxT("...") or _T("...")
OK, I have not previously understood those distinctions.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on February 08, 2011, 02:13:25 pm
dbgextprocess.2(b).patch (b after recent trunk to debugger branch merges)

1)Change various text macro uses, and empty string "" to wxEmptyString
2)Verify that GUI is not gdb specific, but is used for both gdb and cdb (and try Debug external
process with cdb - see item 4)
3)Add cleanup of some overlooked vars on end of Debug external process
4)Fix bug introduced in recent cdb changes affecting Attach to process (new code in GetCommonCommandLine() referencing NULL m_Target) that also affected Debug external process

Awaiting advice on what to do differently than IsExternalProcess()...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 08, 2011, 03:19:06 pm
2)Verify that GUI is not gdb specific, but is used for both gdb and cdb (and try Debug external
process with cdb - see item 4)
Here I'm not talking about CDB, but the new python debugger or another kind of debugger, that can be used only in remote debugging mode (the lua debugger will be just like that if someday I start implementing it). My idea is to move the calling code inside the debugger, so you have the option to implement it or not.
This way the interface is a bit smaller... Also the GUI has too many thing in it.

Awaiting advice on what to do differently than IsExternalProcess()...
This one requires major refactoring. If it doesn't bother you, use your version for now. I'll give it a try myself next week, I think I'll have a bit of free time.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on February 08, 2011, 08:11:55 pm
... If it doesn't bother you, use your version for now...

The current state of the code on which I've already implemented the patch (and brought it forward several times in the past few months)
...does not bother me as much as...
having a patch with functionality 
A)that I find useful,
B)that is (or has been in the past) common functionality in at least 3 other IDEs (borland/cg/embt, visual studio, codelite) so is likely useful to others as well,
C)that does not seem to be philosophically out-of-line with other functionality in the patch target, and
D)that can currently be applied to the code as it is,
E)that does not seem to have any definite practical reason for not being applied

...with a delay in applying it until after some not-yet-begun architectural changes

a)requiring further work on someone's part (to bring it forward yet again) that could be avoided by its application, and
b)the lack of that functionality (no access to it) for others to whom it might be useful now or in the unknown interval when intended architectural changes and required (patch) rework are completed.
c)requires further work on my part to maintain and stay current with the debugger branch for whatever benefit that might provide me (and those working on it for whom I might be able to provide feedback in areas I use)

But, if you do not wish to apply, and the admins agree with that choice, then you may want to at least fix the crash it also addresses in cdb_driver::GetCommonCommandLine() when Attach to process is used with no project opened (which appears to have been introduced with the last previous patches for cdb).
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on February 08, 2011, 08:30:05 pm
...does not bother me as much as...
Please guys, calm down. I believe oBFusCATed is truly willing to accept changes / patches that address the functionalities you have in mind. It is the same for me but I guess all that's missing for now is some more time. I for myself would be willing to try but simply don't have enough time, but I can understand your frustration coming out of this situation.

the admins agree with that choice
I cannot agree atm nor I disagree. When I look at the patch I see a lot TBD's so it seems unfinished to me. We already have a lot TBD's in the debugger plugin so adding more doesn't seem wise from an "outside" point of you. You see: Usually patches we apply are "finished"... even in the development branch (have a look at the history). The goal is to get the branch stable so it can be integrated into trunk. So I hope you also understand our point of view which is no way is disrespecting your work, btw! Every help is absolutely welcome!

However, as a compromise how about applying it for a nightly to give a chance to other users to try. If the community benefits from it we can polish out the ToDo's. But this should clearly be done in a continuous work.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: dmoore on February 08, 2011, 11:13:36 pm
Another options is
Code
MyPlugins::OnAttach(...)
{
    cbDebugger::OnAttach(...);
    ....
}

I actually slightly prefer this because most plugin devs are familiar with OnAttach and OnRelease, and calling a base class method is a familiar idiom (esp. in the wxWidgets world). I don't think OnAttachReal, DoAttach and friends are all that helpful to newbies, because they are basically synonyms of OnAttach that don't convey the nuanced meaning. Anyway, this is a style thing so I'm not going to push too hard (because I'm notorious for bad style).

I have plenty questions about the Debugging API. As a general comment, the cbDebuggerPlugin class definition could definitely use some more documentation, as I'm not always sure what the framework is providing and what the plugin needs to do (lack of time on your part, I know). A couple of specific questions (there will be more):

1. which is responsible for setting and moving the code position marker in the editor: the plugin or the framework? Assuming the framework, which methods need to be implemented in the plugin (and what other calls need to be made or events signalled) to get this to happen?
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...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: dmoore on February 09, 2011, 02:46:56 am
On this:

1. which is responsible for setting and moving the code position marker in the editor: the plugin or the framework? Assuming the framework, which methods need to be implemented in the plugin (and what other calls need to be made or events signalled) to get this to happen?

It appears that correctly implementing IsStopped/IsRunning and then calling SyncEditor from the plugin is enough.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on February 09, 2011, 04:31:22 am
Please guys, calm down. I believe oBFusCATed is truly willing to accept changes / patches that address the functionalities you have in mind. It is the same for me but I guess all that's missing for now is some more time. I for myself would be willing to try but simply don't have enough time, but I can understand your frustration coming out of this situation.
oBFus is probably quite calm, unless I upset him, I probably am the one most needing to calm down, but...

The actual depths of my frustration you have no idea of.  Its roots date back prior to my join date of this forum.

Quote
However, as a compromise how about applying it for a nightly to give a chance to other users to try. <snip> from it we can polish out the ToDo's. But this should clearly be done in a continuous work.
If you wish to apply certainly.

TBD: ToBeDone, ToBeDetermined,ToBeDeleted, ToBeDiscussed

Of the TBD's still present (at least two I should have removed), I don't believe any of them currently require  any action, they are more ToBeDiscussed, if anyone has anything to offer regarding them.

Quote
If the community benefits from it ...
There may be an external community that could benefit if I can meet GPL compliance requirements for mingw built  gdb mods I have.  If the scrolling, leveled/layered, tipwindow can be completed  and incorporated(by someone), I think that would be of great benefit to that potential community as well.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: dmoore on February 09, 2011, 05:54:40 am
I made a little progress tonight on the Python Debugger. For anyone interested in following along, the code is here

Code
svn checkout svn://svn.berlios.de/cbilplugin/trunk/PythonDebugger 

It's still a mess and has quite a few bugs. But you can sort of step through a python program and add/remove breakpoints.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 09, 2011, 08:37:31 am
It appears that correctly implementing IsStopped/IsRunning and then calling SyncEditor from the plugin is enough.
You need to implement GetCurrentPosition too, it is called when an editor is opened.

I have plenty questions about the Debugging API. As a general comment, the cbDebuggerPlugin class definition could definitely use some more documentation, as I'm not always sure what the framework is providing and what the plugin needs to do (lack of time on your part, I know). A couple of specific questions (there will be more):
The main classes you should look at are:
DebuggerManager, the data classes in DebuggerManager.h, the classes for the debug windows and the cbDebuggerPlugin

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...
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.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on February 09, 2011, 07:48:52 pm
... that can be used only in remote debugging mode... My idea is to move the calling code inside the debugger, so you have the option to implement it or not.
Awaiting advice on what to do differently than IsExternalProcess()...
This one requires major refactoring...

oBFus,

As mentioned in a caveat of the original (Debug external program) patch submission inclusion requested further above, I desire to support remote debugging access within the Debug external process functionality.  As also mentioned there, it appears some (possibly significant) study of the remote debugging info handling will be necessary for me to achieve that additional functionality.

Is it likely that your changes relative to remote debugging, and any associated major refactoring are going to affect the current structure and/or use of remote debugging info, such that any work I complete toward that functionality against the current state of the source plus my current changes, will require major rework to bring forward after your changes are completed?

While I would like to move forward in implementing that functionality now, I also do not wish to have to do the work twice, so your feedback on this appreciated...

*** i.e. should I wait to proceed with exploring how to, and subsequently implementing remote debugging within the Debug external program functionality for which I've already requested inclusion, until after you've completed, or report deciding not to, your planned changes in this area?

(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. 

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.)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 09, 2011, 10:04:51 pm
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.

(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. 
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.

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.)
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)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: dmoore on February 09, 2011, 10:15:54 pm
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...
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.

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();
}

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).
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on February 09, 2011, 10:20:13 pm
GDB doesn't support multiple instances at the moment, so no such support is planned. GDB is going to support it
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.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: 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.

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.

[edit]Alternatively, the project may be open in only one codeblocks, but with other codeblocks instances debugging via the Debug external program functionality.
You can open the project in many instances of C::B and use attach to process, the remote case won't work probably.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: dmoore on February 10, 2011, 07:34:13 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.

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();
}


then the framework would work with copies of cbBreakpoint rather than (cbBreakpoint *)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 10, 2011, 09:02:49 pm
In the case for GDB I use them only for internal memory management I think. I don't want to bother with calling
"for each(it in breakpoints) delete *it;". I think this is the only purpose of the shared_ptr here.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: dmoore on February 10, 2011, 09:40:29 pm
In the case for GDB I use them only for internal memory management I think. I don't want to bother with calling
"for each(it in breakpoints) delete *it;". I think this is the only purpose of the shared_ptr here.

Wasn't sure if you were worried about the plugin deleting cbBreakpoint instances while the framework was still using them. I notice that I don't have the tr1 stuff in my current MinGW isntall, which is maybe a small argument for not using shared_ptr. If the framework provides the breakpoint container and manages all of the "delete *it" etc, then probably not a big deal to just use regular pointers... (hides in corner from C++ faithful).
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 10, 2011, 10:11:14 pm
You're using gcc/g++ < 4?
How did you manage to compile the branch, it uses shared_ptr extensively?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: dmoore on February 10, 2011, 10:18:58 pm
You're using gcc/g++ < 4?
How did you manage to compile the branch, it uses shared_ptr extensively?

Well I didn't on this machine, but I have more than one machine (and regularly use both linux and windows). I guess I'm a bit out of date on this windows box.  :?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: dmoore on February 11, 2011, 07:32:59 pm
More questions...

1/ It looks like providing editor tooltips (to instantly "watch" a value) is left completely to the plugin at the moment. Is that right?
2/ Why is const cbStackFrame& GetStackFrame(...) ok, but const cbBreakpoint& GetBreakpoint(...) not? (pointer vs reference consistency issue)
3/ If a debugger doesn't support threads, what should "const cbThread& GetThread(...)" return? Should there be default implementations that do nothing for those?
4/ Likewise, are AttachToProcess, DetachFromProcess, IsAttachedToProcess optional and if so, shouldn't they have default implemetations?
5/ How should a Debugger signal the framework to update the watch and call frame?
6/ Does each debugger use its own debugger log or do they all share one?




Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 11, 2011, 08:00:52 pm
1. Yes
2. GetBreakpoint is the old not added by me, GetStackFrame is added by me I think. Probably they should be made to match
3. return 0 in GetThreadsCount() and GetThread won't be called, you can return return cbThread(), so it will crash if it is called and we could fix, such places
4. It is left to the debugger plugin implementation to decide, what to there, if you feel we need to add default implementation say so
5. Manager::Get()->GetDebuggerManager()->GetWatchesDialog()->UpdateWatches();
6. It is common for all of them.

It you feel we should use pointers everywhere in the GetSomething API, please say so, I'll make a patch... My style/desire is to use references whenever is possible, but looking at it now probably pointers are better here.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: dmoore on February 14, 2011, 08:23:57 pm
It you feel we should use pointers everywhere in the GetSomething API, please say so, I'll make a patch... My style/desire is to use references whenever is possible, but looking at it now probably pointers are better here.

Well I'm not sure either way, but I'd like to do it the same way for Breakpoints/Threads/Watches/CallStack. The slight advantage of the reference is that the caller knows they don't have to delete it. The advantage of returning pointers is that this is far more pervasive in C::B and wxWidgets.

Almost done with a rough version of the Python Debugger. The last major job is to implementing watches, which, admittedly looks rather time consuming ... After that I'll refactor the code and make the interface to pdb a separate class, then implement a class that interfaces with rpdb2 (http://heather.cs.ucdavis.edu/~matloff/winpdb.html), a more suitable python debugger for doing I/O redirection.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: dmoore on February 16, 2011, 05:13:10 am
3 bugs (not ruling out that it is something I have done wrong):

1. After compiling and running the branch + PyDebugger plugin on WinXP, the PyDebugger appeared first on the "Debug -> Active Debuggers" menu. The radio checkbox got stuck on "debugger gdb", but the python debugger was active. It was impossible to reactivate debugger gdb.

2. Breakpoints:
* GDB debugger is active
* Set breakpoints
* Now make python debugger active: the set break points are not activated in the python debugger, but still display in editor.
SUGGESTED FIX: The framework should sync the editor to the breakpoints of the active debugger after switching.

3. Crash after disabling/uninstalling debuggergdb plugin
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: dmoore on February 16, 2011, 05:22:07 am
Also, find I'm exactly copying the watch class implementation of gdb_mi. Move to SDK? (i.e. rename current cbWatch as cbWatchBase, and cbWatch becomes the implementation in gdb_mi)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 16, 2011, 09:27:31 am
Also, find I'm exactly copying the watch class implementation of gdb_mi. Move to SDK? (i.e. rename current cbWatch as cbWatchBase, and cbWatch becomes the implementation in gdb_mi)
If you're sure you won't need anything else it won't be a problem.
But I don't like cbWatchBase, cbWatchSimple is better name for the gdb_mi::Watch?

What do I need to install in order to test your py debugger?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: dmoore on February 16, 2011, 02:22:54 pm
What do I need to install in order to test your py debugger?

Other than what you normally need: Python and a script to debug. On windows, I think you need to put python in your path (but you can point to the location of python interpreter in settings->environment->PyDebugger). You might also need to tweak the project build settings.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 16, 2011, 02:35:27 pm
I'm on linux, so python is runnable...

p.s. The configuration for PyDBG should not be there :)
p.p.s. Settings -> Editor and Settings -> Environment are too confusing already, I always have to open both to find the option I'm looking for :(
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: dmoore on February 16, 2011, 02:46:46 pm
I'm on linux, so python is runnable...

you should be good to go then.

Quote
p.s. The configuration for PyDBG should not be there :)
p.p.s. Settings -> Editor and Settings -> Environment are too confusing already, I always have to open both to find the option I'm looking for :(

Agree, I adapted the code from an old python plugin, which explains all of the cruft. Where are global debugger settings supposed to go?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 16, 2011, 03:07:51 pm
In Compiler & Debugger, but I'm not sure how it is handled at the moment
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Pecan on February 16, 2011, 03:14:44 pm
RE: SVN 6973

"Run to cursor" (to start the debugger session) works. It stops at the cursor position.

"Step Into" does not. It run the complete program without stopping.

Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 16, 2011, 03:20:13 pm
Pecan: Can you past the debugger's debug log?

p.s. Works here, gentoo linux 64bit, gcc 4.4.5, gdb 7.2
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Pecan on February 17, 2011, 02:27:13 pm
Pecan: Can you past the debugger's debug log?

p.s. Works here, gentoo linux 64bit, gcc 4.4.5, gdb 7.2

svn build  rev 6973 (2011-02-07 13:39:14)   gcc 4.3.1 Windows/unicode - 32 bit

Code
// ---------------------------------------------------------------------
Step Into log
// ---------------------------------------------------------------------
PATH=.;C:\Usr\mingw431\bin;C:\WINDOWS\system32;C:\WINDOWS;.;c:\usr\bin;c:\usr\bin\subversion\
Command-line: C:\Usr\mingw431\bin\gdb.exe -nx -fullname  -quiet -args ./debug/codetest.exe
Working dir : C:\temp\test\
> set prompt >>>>>>cb_gdb:
Reading symbols from C:\temp\test/./debug/codetest.exe...done.
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb (GDB) 7.0
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
>>>>>>cb_gdb:
> set confirm off
>>>>>>cb_gdb:
> set width 0
>>>>>>cb_gdb:
> set height 0
>>>>>>cb_gdb:
> set breakpoint pending on
>>>>>>cb_gdb:
> set print asm-demangle on
>>>>>>cb_gdb:
> set unwindonsignal on
>>>>>>cb_gdb:
> set print elements -1
>>>>>>cb_gdb:
> set debugevents on
>>>>>>cb_gdb:
> set new-console on
>>>>>>cb_gdb:
> set disassembly-flavor att
>>>>>>cb_gdb:
> source C:\Usr\Proj\cbDebug\trunk\src\output\share\codeblocks/scripts/stl-views-1.0.3.gdb
>>>>>>cb_gdb:
> directory C:/temp/test/
>>>>>>cb_gdb:
> run
gdb: windows_init_thread_list
[New Thread 1120.0x454]
Error: dll starting at 0x77210000 not found.
Error: dll starting at 0x757e0000 not found.
Error: dll starting at 0x77210000 not found.
Error: dll starting at 0x77330000 not found.
Program exited normally.
>>>>>>cb_gdb:
> set debugevents off
>>>>>>cb_gdb:
> quit


// ---------------------------------------------------------------------
Run to Cursor Log
// ---------------------------------------------------------------------
PATH=.;C:\Usr\mingw431\bin;C:\WINDOWS\system32;C:\WINDOWS;.;c:\usr\bin;c:\usr\bin\subversion\
Command-line: C:\Usr\mingw431\bin\gdb.exe -nx -fullname  -quiet -args ./debug/codetest.exe
Working dir : C:\temp\test\
> set prompt >>>>>>cb_gdb:
Reading symbols from C:\temp\test/./debug/codetest.exe...done.
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb (GDB) 7.0
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
>>>>>>cb_gdb:
> set confirm off
>>>>>>cb_gdb:
> set width 0
>>>>>>cb_gdb:
> set height 0
>>>>>>cb_gdb:
> set breakpoint pending on
>>>>>>cb_gdb:
> set print asm-demangle on
>>>>>>cb_gdb:
> set unwindonsignal on
>>>>>>cb_gdb:
> set print elements -1
>>>>>>cb_gdb:
> set debugevents on
>>>>>>cb_gdb:
> set new-console on
>>>>>>cb_gdb:
> set disassembly-flavor att
>>>>>>cb_gdb:
> source C:\Usr\Proj\cbDebug\trunk\src\output\share\codeblocks/scripts/stl-views-1.0.3.gdb
>>>>>>cb_gdb:
> directory C:/temp/test/
>>>>>>cb_gdb:
> tbreak "C:/temp/test/main.cpp:5"
Temporary breakpoint 1 at 0x401366: file C:\temp\test\main.cpp, line 5.
>>>>>>cb_gdb:
> run
gdb: windows_init_thread_list
[New Thread 4132.0x1200]
Error: dll starting at 0x77210000 not found.
Error: dll starting at 0x757e0000 not found.
Error: dll starting at 0x77210000 not found.
Error: dll starting at 0x77330000 not found.
Temporary breakpoint 1, main () at C:\temp\test\main.cpp:7
C:\temp\test\main.cpp:7:62:beg:0x401366
>>>>>>cb_gdb:
> set debugevents off
>>>>>>cb_gdb:
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 17, 2011, 02:52:56 pm
Does this happen with simple "Hello world" console application?
Or the project is a bit different - native or gui?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Pecan on February 17, 2011, 06:39:57 pm
Does this happen with simple "Hello world" console application?
Or the project is a bit different - native or gui?

It's a simple Hello World created by the wizard.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 17, 2011, 08:34:56 pm
Pecan: I should try it on windows... can you try the latest debugger's branch nightly?

Also next patch is here: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0019.2.patch

What it does:
1. Don't show the breakpoints for the inactive debuggers in the editor's margin. It is refreshed, when the active debugger changes;
2. Extract, some code from CompilerFinished, so it is simpler to implement and less error prone;
3. Document CompilerFinished;
4. Add some logging, when we try to interrupt the debugger;
5. Reorder the source files in the test project file (C::B wants to do it)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: dmoore on February 18, 2011, 03:38:33 am
I need some help with the watches interface. How do I specify that a watch object is expandable without adding children? In python, everything is an object, so it should be possible to expand and see the child members of the object, but I don't want to actually add any children until the user expands the item.

Thx.

EDIT: Would also help if cbWatch included an easy way to recursively iterate through all children of a watch.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 18, 2011, 08:00:15 am
I need some help with the watches interface. How do I specify that a watch object is expandable without adding children? In python, everything is an object, so it should be possible to expand and see the child members of the object, but I don't want to actually add any children until the user expands the item.
Implement:
Code
        virtual void ExpandWatch(cbWatch *watch) = 0;
        virtual void CollapseWatch(cbWatch *watch) = 0;
These are called when the user expands and collapses specific watch, see how it is done in the gdb/mi.
I think you should add dummy initial children (updating in progress for example)...

EDIT: Would also help if cbWatch included an easy way to recursively iterate through all children of a watch.
Patches welcome or please specify the requirement better :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 19, 2011, 11:56:41 pm
Next patch: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0019.3.patch

What it does:
1. Removes "Debug-> Edit Watches...", it was unused;
2. Fixed the OnUpdateUI methods: if there was no active debugger all controls were active, now all controls are disabled;
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Pecan on February 24, 2011, 10:31:46 pm
Pecan: I should try it on windows... can you try the latest debugger's branch nightly?

Also next patch is here: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0019.2.patch

What it does:
1. Don't show the breakpoints for the inactive debuggers in the editor's margin. It is refreshed, when the active debugger changes;
2. Extract, some code from CompilerFinished, so it is simpler to implement and less error prone;
3. Document CompilerFinished;
4. Add some logging, when we try to interrupt the debugger;
5. Reorder the source files in the test project file (C::B wants to do it)


RE: "Step Into" does not break the program as a means to start the debugging session.

I tried the latest nightly *and* the latest debugger branch with the same results. I.e., using Step Into to start the pgm and break on the first statement does not do so. It acts like "run" instead.

This is a simple console "Hello World" generated by the wizard.

svn build  rev 7017 (2011-02-19 13:44:32)   gcc 4.5.1 Windows/unicode - 32 bit

I should also mention that the same problem occurs for me in the regular SVN branch. (windows)

If starting the debugging session with "Step Into" was never intended to work, it should be disabled.

Debugger Log:
Code
Building to ensure sources are up-to-date
Selecting target:
Debug
Adding source dir: C:\temp\test\
Adding source dir: C:\temp\test\
Adding file: .\debug\StepIntoTest.exe
Starting debugger:
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb (GDB) 7.0
Child process PID: 5116
Program exited normally.
Debugger finished with status 0
Debuggers Debug Log:
Code
PATH=.;C:\Usr\mingw431\bin;C:\Windows\system32;C:\Windows;C:\Windows\System32\Wbem;C:\Windows\System32\WindowsPowerShell\v1.0\;c:\Program Files (x86)\ATI Technologies\ATI.ACE\Core-Static;C:\Program Files\Dell\Dell Wireless WLAN Card;C:\Program Files (x86)\Common Files\Roxio Shared\DLLShared\;C:\usr\bin;C:\Program Files (x86)\CollabNet Subversion;C:\Program Files (x86)\TortoiseSVN\bin;C:\Program Files\TortoiseSVN\bin;C:\Program Files (x86)\Common Files\Adobe\AGL
Command-line: C:\Usr\mingw431\bin\gdb.exe -nx -fullname  -quiet -args ./debug/StepIntoTest.exe
Working dir : C:\temp\test\
> set prompt >>>>>>cb_gdb:
Reading symbols from C:\temp\test/./debug/StepIntoTest.exe...done.
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb (GDB) 7.0
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
>>>>>>cb_gdb:
> set confirm off
>>>>>>cb_gdb:
> set width 0
>>>>>>cb_gdb:
> set height 0
>>>>>>cb_gdb:
> set breakpoint pending on
>>>>>>cb_gdb:
> set print asm-demangle on
>>>>>>cb_gdb:
> set unwindonsignal on
>>>>>>cb_gdb:
> set print elements -1
>>>>>>cb_gdb:
> set debugevents on
>>>>>>cb_gdb:
> set new-console on
>>>>>>cb_gdb:
> set disassembly-flavor att
>>>>>>cb_gdb:
> source c:\temp\Nightly\share\codeblocks/scripts/stl-views-1.0.3.gdb
>>>>>>cb_gdb:
> directory C:/temp/test/
>>>>>>cb_gdb:
> run
gdb: windows_init_thread_list
[New Thread 5116.0xca8]
Error: dll starting at 0x77440000 not found.
Error: dll starting at 0x75ff0000 not found.
Error: dll starting at 0x77440000 not found.
Error: dll starting at 0x77560000 not found.
Program exited normally.
>>>>>>cb_gdb:
> set debugevents off
>>>>>>cb_gdb:
> quit
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 28, 2011, 08:56:31 am
Next patch (it doesn't apply for me, but should show you what should be done): http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0019.4.patch

What it does: it removes the debuggertree.h/cpp from svn and the projects (unix only).

Next patch (main patch for the post): http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0020.0.patch

What it does: Reimplement the settings GUI/API for the debuggers;
This patch is intended as a preview, to show the direction I'm going. Dmoore and Morten please take a look at it.
I'm applying it on my main build of C::B and will test it in the next few days then I'll write the complete commit message...

p.s. tested only on linux, so you should modify the windows project if you want C::B to compile :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: dmoore on March 01, 2011, 08:12:31 pm
Next patch (it doesn't apply for me, but should show you what should be done): http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0019.4.patch
...
Next patch (main patch for the post): http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0020.0.patch
...

I applied both patches, which applied with some weirdness (some of this stuff has been applied previously?). C::B builds fine and I can see the new dialog. Looks good, but I haven't spent much time testing the functionality. So what is the major breakage here? :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on March 02, 2011, 12:11:50 am
0019.4 seems applied by Morten.

The main breakage will probably be related to the new "Debug -> Active debuggers -> Target's default" feature.
Also most of the exotic embedded targets won't have correct default settings for the debugger...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on March 03, 2011, 02:32:58 pm
Two new patches:
1. http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0019.5.patch
Fixes:
* Step into was not working on windows (the code was different on windows/mac and linux, not it is the same on all platforms)
* Marked on of the reg expressions to use the wxRE_ADVANCED

2. http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0019.6.patch
Fixes:
* Refactored a bit the stack frame parsing code (extracted it in a function)
* Added tests for stack frame parsing
* Another case of stack frame output is parsed correctly ("#11  0x00406810 in main ()")
* Refactored a bit the debuggergdb test project

All development and testing is done on windows, I'll test it on linux later today. Probably patch 20.0 won't apply anymore, I'll fix that, too.

Morten, can I ask you to reject any patches (even made by me), which change a regexp and don't provide a test for it?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on March 03, 2011, 03:22:56 pm
1. http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0019.5.patch
Concerning this one: Hopefully you noticed that you've removed a work-around for windows, namely stated in this comment:
Code
    // under windows, 'start' segfaults with wx projects...
So either this is fixed in recent GDB's (did you try that functionality on all platforms?), or you might have overseen. Any comment on that?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: dmoore on March 03, 2011, 03:45:24 pm
0019.4 seems applied by Morten.

The main breakage will probably be related to the new "Debug -> Active debuggers -> Target's default" feature.
Also most of the exotic embedded targets won't have correct default settings for the debugger...

Is that because of the various instances of this:

Code
-        m_Programs.DBG = _T("ppc-insight.exe");
+        m_Programs.DBGconfig = wxEmptyString; // _T("ppc-insight.exe");

not sure why you are setting them to empty strings...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on March 03, 2011, 03:52:44 pm
I've tried gdb 6.8 on windows and it works, so I've removed it.
Older GDB's won't work and are unsupported anyway... (don't remember the reasons why :) )
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on March 03, 2011, 04:01:13 pm
not sure why you are setting them to empty strings...
Because I don't generate default debugger configurations to match all the compilers.
And for the default debugger in every compiler I reuse the old field for the debugger's executable.
I can add new field for the compiler's default config, so the old one won't be messed up. The messing up happens only when the default.conf is created, if you have something there and you don't change '--- invalid configuration---' to something valid, the value is preserved.
So if you have new C::B and old C::B, when you switch to old C::B the debugger executable will be correctly set.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on March 04, 2011, 06:42:05 pm
Patch for the unix test project

Code
Index: src/plugins/debuggergdb/debuggergdb_test-unix.cbp
===================================================================
--- src/plugins/debuggergdb/debuggergdb_test-unix.cbp (revision 7038)
+++ src/plugins/debuggergdb/debuggergdb_test-unix.cbp (working copy)
@@ -31,7 +31,8 @@
  <Add directory="$(#unittest_pp)/src" />
  <Add directory="." />
  <Add directory="../../include" />
- <Add directory="../../devel" />
+ <Add directory="../../include/scripting/include" />
+ <Add directory="../../include/scripting/sqplus" />
  </Compiler>
  <Linker>
  <Add option="`wx-config --libs`" />
@@ -46,6 +47,8 @@
  </ExtraCommands>
  <Unit filename="debugger_defs.cpp" />
  <Unit filename="debugger_defs.h" />
+ <Unit filename="debuggergdb_test_backtrace.cpp" />
+ <Unit filename="debuggergdb_test_common.h" />
  <Unit filename="debuggergdb_test_main.cpp" />
  <Unit filename="debuggergdb_test_parser.cpp" />
  <Unit filename="debuggeroptionsprjdlg.h" />

Edit: also a patch to disable the compilation of the resource file:
Code
Index: src/CodeBlocks-unix.cbp
===================================================================
--- src/CodeBlocks-unix.cbp (revision 7038)
+++ src/CodeBlocks-unix.cbp (working copy)
@@ -3286,6 +3304,8 @@
  </Unit>
  <Unit filename="src/resources/resources.rc">
  <Option compilerVar="WINDRES" />
+ <Option compile="0" />
+ <Option link="0" />
  <Option target="src" />
  </Unit>
  <Unit filename="src/resources/scripting_settings.xrc">
(There is a chance it won't apply)


Edit2: Here is the fixed 20.0.patch: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0020.1.patch
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: xhpohanka on March 16, 2011, 11:51:05 am
Hello,
thank you for the hard work on debugger in CB.
I have one question regarding the automatic dereferencing of the watches -> I mean will there be a feature, which allows to automatically expand watched pointer to a struct?
I use CB on windows with mingw32 gdb.

regards, Jan
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on March 16, 2011, 12:48:06 pm
No (99% probability), with the current plugin.
If the gdb/mi plugin is finished in the future, it will do it automatically (already does).
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: xhpohanka on March 16, 2011, 12:50:04 pm
No (99% probability), with the current plugin.
If the gdb/mi plugin is finished in the future, it will do it automatically (already does).

Thanks for the answer. Where can I get gdb/mi plugin please (even the devel version)?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on March 16, 2011, 01:15:43 pm
Search the topic, you'll find a link to my svn, but at the moment it is unlikely to work with the vanilla source of the branch...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: xhpohanka on March 17, 2011, 08:52:21 am
Search the topic, you'll find a link to my svn, but at the moment it is unlikely to work with the vanilla source of the branch...

Thank you, I have found it.
Another small question: important features are still missing in debugger GUI, local vars, function params and maybe global vars. Is their implementation in the project roadmap, please?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on March 17, 2011, 09:23:28 am
Another small question: important features are still missing in debugger GUI, local vars, function params and maybe global vars. Is their implementation in the project roadmap, please?
Yes, but they are missing because they are not so important :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: m.29 on April 08, 2011, 08:49:00 pm
I noticed some weird behaviour. Output for GDB is not parsed correctly if there is "repeats X times" substring. As you can see on picture strarr is the array with 3 strings, but it is parsed as array with only 2 values. I tried some modifications in ParseGDBWatchValue function, but there is too many flags for me :-(

[attachment deleted by admin]
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on April 08, 2011, 09:37:41 pm
m.29: Confirmed, I've added a test probably will try to fix it later...

BTW:
Anyone against the changes to the settings I've made with the 0020.x.patches?
I was planning to commit the patch in the next couple of days.
There are some gui problems on windows, but I'll fix them when I commit the patch (I'm sure it is not big deal, but it is too complex to manage).
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on April 08, 2011, 09:46:37 pm
Anyone against the changes to the settings I've made with the 0020.x.patches?
From my side: Go ahead. Seems to work here.

I tried some modifications in ParseGDBWatchValue function, but there is too many flags for me :-(
This screenshot of yours looks very promising. What a nice work! 8)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on April 08, 2011, 10:59:04 pm
m.29: Confirmed, I've added a test probably will try to fix it later...
And fixed.
If there more such cases, post the output from gdb and I'll fix them(if possible.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: m.29 on April 09, 2011, 12:05:45 am
This screenshot of yours looks very promising. What a nice work! 8)
Thanks :)

tO oBFusCATed:
Only these two are still broken. If I find any others I post them here.
Code
{0x4080d8 "1st", 0x4080dc "2rd", '.' <repeats 48 times>, 0x408110 "3th"}
{0x4080d8 "1st", 0x4080dc '.' <repeats 14 times>, "#", '&' <repeats 16 times>, 0x4080fc "3th"}
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on April 09, 2011, 11:55:09 am
m.29: Fixed
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: m.29 on April 10, 2011, 09:32:28 pm
Thanks for fixes, but after new commits I get SIGSEGV when I close Code::Blocks. It breaks in debuggermenu.cpp on line 199. Here is my debug log.
Code
Building to ensure sources are up-to-date
Selecting target:
src
Adding source dir: C:\proj1\clean_cb\src\
Adding source dir: C:\proj1\clean_cb\src\
Adding file: C:\proj1\clean_cb\src\devel\codeblocks.exe
Changing directory to: C:/proj1/clean_cb/src/devel
Starting debugger:
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb 6.8
Child process PID: 992
At C:\proj1\clean_cb\src\sdk\debuggermenu.cpp:199
Continuing...
At C:\proj1\clean_cb\src\sdk\debuggermenu.cpp:199
Continuing...
At C:\proj1\clean_cb\src\sdk\debuggermenu.cpp:199
Program received signal SIGSEGV, Segmentation fault.
In wxMenuItem::Check () (C:\unix\wxWidgets-2.8.11\lib\gcc_dll\wxmsw28u_gcc_custom.dll)
#1  0x00cf4e9d in DebuggerMenuHandler::RebuildActiveDebuggersMenu (this=0x48401e0) at C:\proj1\clean_cb\src\sdk\debuggermenu.cpp:199
C:\proj1\clean_cb\src\sdk\debuggermenu.cpp:199:8979:beg:0xcf4e9d
At C:\proj1\clean_cb\src\sdk\debuggermenu.cpp:199
#1  0x00cf4e9d in DebuggerMenuHandler::RebuildActiveDebuggersMenu (this=0x48401e0) at C:\proj1\clean_cb\src\sdk\debuggermenu.cpp:199
C:\proj1\clean_cb\src\sdk\debuggermenu.cpp:199:8979:beg:0xcf4e9d
Continuing...
Program received signal SIGSEGV, Segmentation fault.
In wxMenuItem::Check () (C:\unix\wxWidgets-2.8.11\lib\gcc_dll\wxmsw28u_gcc_custom.dll)
#1  0x00cf4e9d in DebuggerMenuHandler::RebuildActiveDebuggersMenu (this=0x48401e0) at C:\proj1\clean_cb\src\sdk\debuggermenu.cpp:199
C:\proj1\clean_cb\src\sdk\debuggermenu.cpp:199:8979:beg:0xcf4e9d
At C:\proj1\clean_cb\src\sdk\debuggermenu.cpp:199
#1  0x00cf4e9d in DebuggerMenuHandler::RebuildActiveDebuggersMenu (this=0x48401e0) at C:\proj1\clean_cb\src\sdk\debuggermenu.cpp:199
C:\proj1\clean_cb\src\sdk\debuggermenu.cpp:199:8979:beg:0xcf4e9d
Continuing...
Program exited with code 030000000005.
Debugger finished with status 0
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on April 10, 2011, 09:51:27 pm
Hm, pretty strange...
Unfortunately the menus behave differently on windows and at the moment I'm investigating a ::Check related problem.
For some reason calling wxMenu::Check() can fail and the result is that there is no active debugger selected.

If you need to do some real work on C::B please revert to r7086, until I fix the problem or if you can track it, the better :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on April 11, 2011, 09:25:30 pm
m.29:
I've committed a fix for the menu handling, can you try it?
If it crashes again please provide the full steps needed to reproduce it.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: m.29 on April 11, 2011, 11:20:54 pm
Sorry for my late answer - busy day today. I tried it and it seems to be all right. Great work :-)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: m.29 on April 18, 2011, 02:33:26 pm
Some new bug in r7121 :-( I just open Code::Blocks then select Settings -> Debugger... and C::B crash on line 97 in file debuggeroptionsdlg.cpp.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on April 18, 2011, 03:02:22 pm
Execute src/update or src/update.bat depending on your OS...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: xhpohanka on April 21, 2011, 01:11:14 pm
Hello, work on the debugger GUI is promising, but I'd like to ask you - is there a possibility to simply delete or rename a watched variable? I mean by pressing del, or f2 to rename or something similar, not only using context menu. Also I'm lacking the possibility of changing the format (decimal, hex, unsigned, ...) for member variables in expanded structure or class.

Nevertheless the new GUI works really well... Thank you.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on April 21, 2011, 01:18:14 pm
Yes, use linux  :lol: (the buttons are delete and insert)
Something is happening on windows and the shortcuts doesn't work.
I've to investigate why. It is on the TODO list.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on May 02, 2011, 09:33:46 pm
dmoore:
Do you think to work on your debugger plugin soon?
I've tried it bug it failed to compile. I've fixed the compilation (I can provide the patch if you're interested),
but it crashed C::B (should fix the API a bit, but this will be done later), because the new configuration staff is missing.

p.s. have you though of using wxSmith for the GUI? If you use wxSmith it will be easier for others to modify your GUIs, and contribute:)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on May 03, 2011, 04:14:39 am
(items quoted were posted almost 3 months ago back on page 28 of thread)
1of3)Morten, regarding
However, as a compromise how about applying it for a nightly to give a chance to other users to try. If the community benefits from it we can polish out the ToDo's. But this should clearly be done in a continuous work.
My patch does not appear to have been applied to any nightly.  Oversight on my part, or current plans concerning this?

2of3)oBFusCATed , regarding
This one requires major refactoring. If it doesn't bother you, use your version for now. I'll give it a try myself next week, I think I'll have a bit of free time.
Any progress I've overlooked on this refactoring, or if not, a timeline yet when this might be sufficiently complete to host my previously submitted functionality in a form acceptable to you?

3of3)oBFusCATed /Others, the crash possible in Attach to process previously introduced with earlier cdb support related patches does not seem to have been corrected (outside of the not yet accepted/applied patch [with other functionality] I previously submitted.)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on May 03, 2011, 08:49:19 am
Can you state the name of the patches (or direct links to the posts)?

3of3)oBFusCATed /Others, the crash possible in Attach to process previously introduced with earlier cdb support related patches does not seem to have been corrected (outside of the not yet accepted/applied patch [with other functionality] I previously submitted.)
I've missed this, this could be applied (faster) if you supply a separate patch...(and steps to reproduce the crashes)

BTW Your tooltips patch won't be applied, because it is broken badly on my linux (gentoo + e17). It is pretty complex in its mouse handing/interactions, so it will be hard to maintain.
I've started separate implementation using wxPopupTransientWindow and wxPropertyGrid.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on May 03, 2011, 12:28:59 pm
Can you state the name of the patches (or direct links to the posts)?
dbgextprocess.2b.patch
http://forums.codeblocks.org/index.php/topic,10908.msg95323.html#msg95323
I believe the fix for the issue was merely to make sure m_Target is not NULL before attempting to use to check for ttConsoleOnly.

3of3)oBFusCATed /Others, the crash possible in Attach to process previously introduced with earlier cdb support related patches does not seem to have been corrected (outside of the not yet accepted/applied patch [with other functionality] I previously submitted.)
I've missed this, this could be applied (faster) if you supply a separate patch...(and steps to reproduce the crashes)
I believe you merely had to start codeblocks without opening a project and then perform an Attach to process.

BTW Your tooltips patch won't be applied, because it is broken badly on my linux (gentoo + e17). It is pretty complex in its mouse handing/interactions, so it will be hard to maintain.
OK.  
("broken" I accept as reason not to aply.  
Complex to maintain I don't accept, unless a)it can be reasonably speculated that some desired functionality will likely have to be added, or, b)that the functiionality it provides is not useful and desireable, or c)that there is a simpler way to accomplish the same functionality without the complexity, or d)it makes use of wxwidgets features that are known to be platform inconsistent, or unstable or likely to change [possibly the situation if it is "broken" on linux].

Further, it was merely intended as a prototype, not necessarily to be applied in its current state - all of that code was exploratory, with regard to the windows without borders on both Windows and Linux and possibly other issues I don't recall at this point)

I've started separate implementation using wxPopupTransientWindow and wxPropertyGrid.
OK.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on May 03, 2011, 01:41:11 pm
I believe the fix for the issue was merely to make sure m_Target is not NULL before attempting to use to check for ttConsoleOnly.
Can you check it, again?

dbgextprocess.2b.patch
I can't give you a time frame for the refactoring. At the moment I'm working on tooltips, as they have more impact on users and plugin writers.

OK. 
("broken" I accept as reason not to aply. 
Complex to maintain I don't accept, unless a)it can be reasonably speculated that some desired functionality will likely have to be added, or, b)that the functiionality it provides is not useful and desireable, or c)that there is a simpler way to accomplish the same functionality without the complexity, or d)it makes use of wxwidgets features that are known to be platform inconsistent, or unstable or likely to change [possibly the situation if it is "broken" on linux].

Further, it was merely intended as a prototype, not necessarily to be applied in its current state - all of that code was exploratory, with regard to the windows without borders on both Windows and Linux and possibly other issues I don't recall at this point)
The thing is that it does many complex things with windows. It needs borderless windows, it needs correctly working hovering.
And implementing this on all platforms will be hard and will increase the maintenance cost.
I'll see if my approach will be simpler. It will be something like this: http://monodevelop.com/@api/deki/files/286/=md24-PinnedDebugValues.png
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on June 02, 2011, 05:11:52 pm
OK, I've done some work on the tooltips and there are some problems :(

The main problem is that the keyboard input inside wxPopupWindow is very buggy or it even doesn't work (on wxMSW).  :evil: :twisted: :cry: :?: :|  :x :shock: :?

The simplest solution is to surrender and make the tooltips read-only. Not a good solution from the usability point of view.
Has anyone done any complex tooltips using wxWidgets?

I'll post a patch with read-only tooltips later today...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on August 10, 2011, 09:52:40 pm
Ok, I have the patch for the tooltips almost ready: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0022.3.patch

Please test it. I'm using it every day on my linux, but have done very little testing on windows, so feedback is welcome.

Changes:
- Added API for showing value tooltips from debugger plugins
- Added implementation of the tooltip using wxPropertyGrid
- Imported std::tr1::shared_ptr in namespace cb, replaced all usages of std::tr1::shared_ptr with cb::shared_ptr (this should make it very easy to change the shader_ptr implementation)
- Some of the functions have been changed to return or take cbWatch::Pointer instead of raw pointers (all should be changed, but this will be done later)
- Added 'Require Ctrl key to be pressed to show the Value tooltip'
- Changed wxPropertyGrid to support the autosizing (logged issue request upstream)
- Added code to correctly hide the CC tooltips
- Some refactoring here and there.

Feedback please...
If there are no reports for problems, I'll commit in the next couple of weeks...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on August 10, 2011, 09:55:50 pm
Please test it. I'm using it every day on my linux, but have done very little testing on windows, so feedback is welcome.
Would you mind to commit for testing? This would make things a little easier.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on August 11, 2011, 04:18:08 am
The patch is only partially applied in the debugger branch.
I just update to rev 7362, but found that it's hard to apply the patch. So, I revert back to rev 7342, and apply the patch. :D

@obF:
cbEVT_EDITOR_TOOLTIP is sent from cbEditor to notify all the plugins, and which is cause by receiving the DWellStart event from scintilla control.

Code
    Connect( m_ID,  -1, wxEVT_SCI_DWELLSTART,
                  (wxObjectEventFunction) (wxEventFunction) (wxScintillaEventFunction)
                  &cbEditor::OnEditorDwellStart );

and

Code
void cbEditor::OnEditorDwellStart(wxScintillaEvent& event)
{
    if (!wxTheApp->IsActive())
        return;

    cbStyledTextCtrl* control = GetControl();
    if (!control)
        return;

    wxRect screenRect = control->GetScreenRect();
    wxPoint ptEvent(event.GetX(), event.GetY());
    ptEvent = control->ClientToScreen(ptEvent);
    wxPoint ptScreen = wxGetMousePosition();
    wxPoint ptClient = control->ScreenToClient(ptScreen);

    double distance = sqrt(  (ptScreen.x - ptEvent.x) * (ptScreen.x - ptEvent.x)
                           + (ptScreen.y - ptEvent.y) * (ptScreen.y - ptEvent.y) );
    if (!screenRect.Contains(ptScreen) || distance > 10)
        return;

    int pos = control->PositionFromPoint(ptClient);
    int style = control->GetStyleAt(pos);
    NotifyPlugins(cbEVT_EDITOR_TOOLTIP, style, wxEmptyString, ptClient.x, ptClient.y);
    wxScintillaEvent newEvent(event);
    newEvent.SetX(ptClient.x);
    newEvent.SetY(ptClient.y);
    OnScintillaEvent(event);
}

and
Code
void wxScintilla::NotifyParent (SCNotification* _scn)
{
    SCNotification& scn = *_scn;
    wxScintillaEvent evt (0, GetId());

    evt.SetEventObject(this);
    evt.SetPosition(scn.position);
    evt.SetKey(scn.ch);
    evt.SetModifiers(scn.modifiers);

    switch (scn.nmhdr.code) {
    case SCN_STYLENEEDED:
        evt.SetEventType (wxEVT_SCI_STYLENEEDED);
        break;
    .......
    .......
    case SCN_DWELLSTART:
        evt.SetEventType (wxEVT_SCI_DWELLSTART);
        evt.SetX(scn.x);
        evt.SetY(scn.y);
        break;

the logic of sending SCN_DWELLSTART is much simple. in scintilla control, there is a timer, when the control received the MouseMove event, it will always restart the timer, if for about 500ms there is not MouseMove event happens, then the timer event handler will  be fired, and send a SCN_DWELLSTART event.
Any MouseMove or keypress will let restart the timer and send a SCN_DWELLEND event.

Applying your patch, I see that both codecompletion plugin and debugger plugin will have a handler to response the cbEVT_EDITOR_TOOLTIP event from SDK, I found such code in debugger's handler:

Code
void cbDebuggerPlugin::ProcessValueTooltip(CodeBlocksEvent& event)
{
    event.Skip();
    if (cbDebuggerCommonConfig::GetFlag(cbDebuggerCommonConfig::RequireCtrlForTooltips))
    {
        if (!wxGetKeyState(WXK_CONTROL))
            return;
    }

    if (!ShowValueTooltip(event.GetInt()))
        return;

    EditorBase* base = event.GetEditor();
    cbEditor* ed = base && base->IsBuiltinEditor() ? static_cast<cbEditor*>(base) : 0;
    if (!ed)
        return;

    if (ed->IsContextMenuOpened())
        return;

    // get rid of other calltips (if any) [for example the code completion one, at this time we
    // want the debugger value call/tool-tip to win and be shown]
    if (ed->GetControl()->CallTipActive())
        ed->GetControl()->CallTipCancel();

    wxPoint pt;
    pt.x = event.GetX();
    pt.y = event.GetY();

    const wxString &token = GetEditorWordAtCaret(&pt);
    if (!token.empty())
    {
        pt = ed->GetControl()->ClientToScreen(pt);
        OnValueTooltip(token, wxRect(pt.x - 5, pt.y, 10, 10));
    }
}
This has the assumption that CC's handler is running before the debugger's handler. In-fact, there is no grantee which tip handler will run before other one. if CC's handler runs later, it will destroy the debugger's tip. This is a race condition. :D we have discussed before.

also, this code:
Code
    if (cbDebuggerCommonConfig::GetFlag(cbDebuggerCommonConfig::RequireCtrlForTooltips))
    {
        if (!wxGetKeyState(WXK_CONTROL))
            return;
    }
Does not works under Windows for sure. I have exam this condition before. Under windows, if you hold the control key, then the timer in scintilla control will notice that your have press a key, and do a restart always, and the time handler never fired. (I'm not sure how the scintilla control was implemented under Linux), even though the SCN_DWELLSTART is already send, when detecting the ctrl key, it will quickly send a SCN_DWELLEND event to destroy the tip.

The other issue is related in my post:
DWELL Windows Question (https://groups.google.com/d/topic/scintilla-interest/fRCdbpxqGPU/discussion)
I can filter the ctrl key, so the sci control send SCN_DWELLSTART event does not consider the ctrl condition. the client has the duty to check whether show or disable the tip depend on the ctrl key condition. After your tip window is shown, if you still hold on the ctrl key. the tip window will received the key press event, and destroy the tip. at this condition, you need to filter the ctrl key event in the tip window too.






Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on August 11, 2011, 08:39:39 am
The patch is only partially applied in the debugger branch.
I just update to rev 7362, but found that it's hard to apply the patch. So, I revert back to rev 7342, and apply the patch. :D
Yes, sorry for that but my batteries hit the low end and I had to go to bed :(

This has the assumption that CC's handler is running before the debugger's handler. In-fact, there is no grantee which tip handler will run before other one. if CC's handler runs later, it will destroy the debugger's tip. This is a race condition. :D we have discussed before.
Do you know a better way? I don't, so this is the best we can do at the moment. And it works.
Some day I could rewrite the whole systems, so both tooltips could be visible.

also, this code:
Code
    if (cbDebuggerCommonConfig::GetFlag(cbDebuggerCommonConfig::RequireCtrlForTooltips))
    {
        if (!wxGetKeyState(WXK_CONTROL))
            return;
    }
Does not works under Windows for sure. I have exam this condition before. Under windows, if you hold the control key, then the timer in scintilla control will notice that your have press a key, and do a restart always, and the time handler never fired. (I'm not sure how the scintilla control was implemented under Linux), even though the SCN_DWELLSTART is already send, when detecting the ctrl key, it will quickly send a SCN_DWELLEND event to destroy the tip.

The other issue is related in my post:
DWELL Windows Question (https://groups.google.com/d/topic/scintilla-interest/fRCdbpxqGPU/discussion)
I can filter the ctrl key, so the sci control send SCN_DWELLSTART event does not consider the ctrl condition. the client has the duty to check whether show or disable the tip depend on the ctrl key condition. After your tip window is shown, if you still hold on the ctrl key. the tip window will received the key press event, and destroy the tip. at this condition, you need to filter the ctrl key event in the tip window too.
I'm not sure I understand, can you provide a patch (after I commit everything)?




Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on August 11, 2011, 08:53:10 am
The patch is only partially applied in the debugger branch.
I just update to rev 7362, but found that it's hard to apply the patch. So, I revert back to rev 7342, and apply the patch. :D
Yes, sorry for that but my batteries hit the low end and I had to go to bed :(
:D

Quote
Do you know a better way? I don't, so this is the best we can do at the moment. And it works.
Some day I could rewrite the whole systems, so both tooltips could be visible.
We have a discussion here:
show debugger tip under curser when ctrl key is pressed (http://forums.codeblocks.org/index.php/topic,13875.msg93398.html#msg93398)
and race condition explanation by jens (http://forums.codeblocks.org/index.php/topic,10708.msg73482.html#msg73482)
also you said it works on Linux (http://forums.codeblocks.org/index.php/topic,13875.msg93399.html#msg93399)

Quote
I'm not sure I understand, can you provide a patch (after I commit everything)?

The patch is already here (http://forums.codeblocks.org/index.php/topic,13875.msg93580.html#msg93580), but I think that the way in codelite is much better ( it emulate an event, also it handle the race condition ).




Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on August 11, 2011, 09:57:01 am
OK, I'll see what can be done tonight.
Can you show me the exact revisions of the changes in CodeLight?

Everything is committed now. Happy testing.

btw. DBG tooltip almost always wins (it is shown later), because there is some delay evaluating the variable.  8)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on August 11, 2011, 10:03:53 am
OK, I'll see what can be done tonight.
Can you show me the exact revisions of the changes in CodeLight?
It's also in the same post: codelite's way to emulate a event when ctrl pressed (http://forums.codeblocks.org/index.php/topic,13875.msg93580.html#msg93580).
Codelite has the code repository on sourceforge:SourceForge.net: CodeLite: SCM (http://sourceforge.net/scm/?type=svn&group_id=202033)

Quote
Everything is committed now. Happy testing.
btw. DBG tooltip almost always wins (it is shown later), because there is some delay evaluating the variable.  8)
Thanks and that's great!
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on August 11, 2011, 03:36:58 pm
by the way, codelite has a tip improvement, see:

Quote
Revision: 4686
Author: eranif
Date: 2:39:01, 2011 1 3
Message:
- Debugger: when the option to show the debugger tip only if CTRL key is down is ON, the tip will now be shown immediately without the need to "move" the mouse
----
Modified : /trunk/LiteEditor/cl_editor.cpp
Modified : /trunk/LiteEditor/context_cpp.cpp

In this rev, an emulated event is added.


Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on August 11, 2011, 04:25:18 pm
I'll look at it.... thanks
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on August 11, 2011, 04:37:35 pm
One change in the scintilla editor should be like below:
Code
Index: E:/code/cb/cb_debugger_branch/src/sdk/wxscintilla/src/scintilla/src/Editor.cxx
===================================================================
--- E:/code/cb/cb_debugger_branch/src/sdk/wxscintilla/src/scintilla/src/Editor.cxx (revision 7366)
+++ E:/code/cb/cb_debugger_branch/src/sdk/wxscintilla/src/scintilla/src/Editor.cxx (working copy)
@@ -5580,7 +5580,9 @@
 }
 
 int Editor::KeyDownWithModifiers(int key, int modifiers, bool *consumed) {
- DwellEnd(false);
+    //any key other than ctrl will cause the dwell end
+    if(modifiers!=SCI_CTRL)
+        DwellEnd(false);
  int msg = kmap.Find(key, modifiers);
  if (msg) {
  if (consumed)

Compare with my last patch: my last patch (http://forums.codeblocks.org/index.php/topic,13875.msg93580.html#msg93580)
it seem you did not use "GDBTipWindowView" or "GDBTipWindow" to show the tip?

as you said:
Quote
- Added implementation of the tooltip using wxPropertyGrid
, does this tip only used for watch dialog?

I just exam the code:
Code
void cbDebuggerPlugin::ProcessValueTooltip(CodeBlocksEvent& event)
{
    event.Skip();
    if (cbDebuggerCommonConfig::GetFlag(cbDebuggerCommonConfig::RequireCtrlForTooltips))
    {
        if (!wxGetKeyState(WXK_CONTROL))
            return;
    }

    if (!ShowValueTooltip(event.GetInt()))
        return;

    EditorBase* base = event.GetEditor();
    cbEditor* ed = base && base->IsBuiltinEditor() ? static_cast<cbEditor*>(base) : 0;
    if (!ed)
        return;

    if (ed->IsContextMenuOpened())
        return;

    // get rid of other calltips (if any) [for example the code completion one, at this time we
    // want the debugger value call/tool-tip to win and be shown]
    if (ed->GetControl()->CallTipActive())
        ed->GetControl()->CallTipCancel();

    wxPoint pt;
    pt.x = event.GetX();
    pt.y = event.GetY();

    const wxString &token = GetEditorWordAtCaret(&pt);
    if (!token.empty())
    {
        pt = ed->GetControl()->ClientToScreen(pt);
        OnValueTooltip(token, wxRect(pt.x - 5, pt.y, 10, 10));
    }
}
So, where did you actually show the debugger's tip window? In the function
Code
OnValueTooltip(token, wxRect(pt.x - 5, pt.y, 10, 10));
??
I can't see any code snippet to show the tip window. :D
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on August 11, 2011, 05:07:17 pm
Compare with my last patch: my last patch (http://forums.codeblocks.org/index.php/topic,13875.msg93580.html#msg93580)
it seem you did not use "GDBTipWindowView" or "GDBTipWindow" to show the tip?
No, I don't :)
See the ValueTooltip class.

as you said:
Quote
- Added implementation of the tooltip using wxPropertyGrid
, does this tip only used for watch dialog?
No, it is not used for the watches, but the value tooltips, set the ValueTooltip class...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on August 11, 2011, 11:05:01 pm
One annoying thing I found:
if "build to ensure, that project is up to date" is checked, the build-process can not be interrupted if it has started.
In trunk this is still possible.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on August 11, 2011, 11:07:39 pm
I know, I have it in the to-do.

This http://smrt.is-a-geek.org/codeblocks/TODO is the full to-do if someone is interested :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on August 12, 2011, 03:37:33 am
Compare with my last patch: my last patch (http://forums.codeblocks.org/index.php/topic,13875.msg93580.html#msg93580)
it seem you did not use "GDBTipWindowView" or "GDBTipWindow" to show the tip?
No, I don't :)
See the ValueTooltip class.
Thanks, I found it, it was in parsing the gdb command output, here:
Code
/**
  * Command to display a tooltip about a variables value.
  */
class GdbCmd_TooltipEvaluation : public DebuggerCmd
{
        wxRect m_WinRect;
        wxString m_What;
        wxString m_Type;
        wxString m_Address;
        wxString m_ParseFunc;
    public:
        /** @param what The variable to evaluate.
            @param win A pointer to the tip window pointer.
            @param tiprect The tip window's rect.
        */
        GdbCmd_TooltipEvaluation(DebuggerDriver* driver, const wxString& what, const wxRect& tiprect, const wxString& w_type = wxEmptyString, const wxString& address = wxEmptyString)
            : DebuggerCmd(driver),
            m_WinRect(tiprect),
            m_What(what),
            m_Type(w_type),
            m_Address(address)
        {
            m_Type.Trim(true);
            m_Type.Trim(false);
            m_Cmd = static_cast<GDB_driver*>(m_pDriver)->GetScriptedTypeCommand(w_type, m_ParseFunc);
            if (m_Cmd.IsEmpty())
            {
                // if it's a pointer, automatically dereference it
                if (w_type.Length() > 2 && // at least 2 chars
                    w_type.Last() == _T('*') && // last is *
                    w_type.GetChar(w_type.Length() - 2) != _T('*') && // second last is not * (i.e. doesn't end with **)
                    !w_type.Contains(_T("char "))) // not char* (special case)
                {
                    m_What = wxT("*") + m_What;
                }

                m_Cmd << wxT("output ");
                m_Cmd << m_What;
            }
            else
            {
                try
                {
                    SqPlus::SquirrelFunction<wxString&> f(cbU2C(m_Cmd));
                    m_Cmd = f(w_type, what, 0, 0);
                }
                catch (SquirrelError e)
                {
                    m_Cmd = cbC2U(e.desc);
                    m_pDriver->DebugLog(_T("Script exception: ") + m_Cmd);
                }
            }
        }
        void ParseOutput(const wxString& output)
        {
            wxString contents;
            if (output.StartsWith(_T("No symbol ")) || output.StartsWith(_T("Attempt to ")))
                contents = output;
            else
            {
                if (!m_ParseFunc.IsEmpty())
                {
                    try
                    {
                        SqPlus::SquirrelFunction<wxString&> f(cbU2C(m_ParseFunc));
                        contents << f(output, 0);
                    }
                    catch (SquirrelError e)
                    {
                        contents << cbC2U(e.desc);
                        m_pDriver->DebugLog(_T("Script exception: ") + contents);
                    }
                }
                else
                {
                    contents << output;
                    // the following breaks the text when it *is* a hex number
//                    if (reGenericHexAddress.Matches(output))
//                    {
//                        contents.Replace(reGenericHexAddress.GetMatch(output, 1), _T(""));
//                        contents.Trim(false);
//                    }
                }
            }
            contents.Trim(true);
            contents.Trim(false);

            GDBWatch::Pointer watch(new GDBWatch(m_What));
            watch->SetType(m_Type);

            ParseGDBWatchValue(*watch, contents);

            if (Manager::Get()->GetDebuggerManager()->ShowValueTooltip(watch, m_WinRect))
            {
                watch->SetForTooltip(true);
                m_pDriver->GetDebugger()->AddWatchNoUpdate(watch);
            }
        }
};

I know, I have it in the to-do.
This http://smrt.is-a-geek.org/codeblocks/TODO is the full to-do if someone is interested :)
too many todos.
about the python pretty printer, the latest cvs version of GDB has supply some command like:
"info pretty-printer" to show the installed pretty printers.
"enable/disable pretty-printer" to enable/disable this feature.
These feature can be added when you have some gdb's own pretty-printer utilities scripts in share/gdb folder (I only tested under MinGW).
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on August 12, 2011, 08:59:56 am
a test patch(based on rev 7366 debugger branch) to enable this feature(emulate a message when ctrl pressed when debugging)
need for testing :D
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on August 12, 2011, 09:27:22 am
too many todos.
I'm adding more items, then removing  8)

a test patch(based on rev 7366 debugger branch) to enable this feature(emulate a message when ctrl pressed when debugging)
need for testing :D
I'll test it on linux...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on August 12, 2011, 09:39:49 am
Another thing to put onto your todo-list (if it is possible):
make the font of the tooltip configurable, at least the size.
It's very small on my 1920x1200 17" laptop.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on August 12, 2011, 10:02:54 am
Yes, this is in the TO-DO inside my head:)
My idea is to have it as an offset from the default font.
Is this OK or would you prefer a fixed setting?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on August 12, 2011, 03:03:37 pm
Is this OK or would you prefer a fixed setting?
If you ask such a question, the answer is clear:
Make it configurable, but initialised with an offset from the default font... ;-) :lol:
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on August 12, 2011, 03:23:57 pm
No, I won't add two settings! There are plenty of options in the config dialogs already.
My desire is to trim the number of options no increasing it.
Adding an option is the easiest way for the developer, but not for the user:)

It would be an offset from the default font OR a number specifying the size of the font.
(I could add some mumbo-jumbo to calculate the default with an offset, but I'm not sure I like the idea)

My preference is an offset, because if the user changes his/her default font - the tooltips will change automagically.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on August 12, 2011, 03:42:32 pm
I would prefer it fully configurable with a reasonable default value (e.g. same font as editor, with a smaller size).

It's just one button, to chose the font and all parameters like in the ditor settings, that should not be too much for the users.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on August 12, 2011, 03:46:54 pm
I use the default font at the moment. The font in the editor has other requirements (monospace-ness).

OK, I would implement the same GUI as the editor's font settings.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on August 12, 2011, 04:29:32 pm
Patch v2(still against rev 7366), though I have done every thing to emulate a cb event, it seems I still failed to show the debugger's tip when ctrl pressed. hope some one can help, thanks.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: dmoore on August 12, 2011, 05:38:15 pm
Hi Guys! Long time no post.

No, I won't add two settings! There are plenty of options in the config dialogs already.

Off Topic: Agree that its cluttered, but that's a reflection of a bad UI for settings, not too many settings. I think we need some mechanism for changing advanced settings that doesn't involve hand editing xml, such as a searchable property sheet, so that we can give new users simpler settings dialogs and advanced users more flexibility.

On Topic: I should probably just read the thread/code, but do you have a cliff notes version of the status of your work on the debugger API, oBFus? (May have some free time to think about the python debugger again in coming months)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on August 12, 2011, 05:55:06 pm
dmoore: Probably you're right that something like "about:config" will be very handy.... :)

Regarding the API, I plan to replace all the raw pointers with cb::shared_ptr (where applicable of course) and then I'll focus on the gdb_mi plugin for a while...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on August 13, 2011, 05:07:47 pm
Patch v2(still against rev 7366), though I have done every thing to emulate a cb event, it seems I still failed to show the debugger's tip when ctrl pressed. hope some one can help, thanks.
Ok, I solved the problems in v2 patch, and now when I hit the ctrl key, the debugger will show the tip now. (test only under WinXP). the reason v2 failed is that I forget setting the editor pointer in the emulated c::b event.

see the v3 patch (which is against debugger_branch rev 7376), note I have some DebugLog function in the patch, you can safely remove them. I admit that the emulated way is not quite good, it looks like a hack. :D

comments are welcome!
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on August 14, 2011, 01:50:29 am
Here is my take at the problem: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0022.5.patch
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on August 14, 2011, 04:39:42 am
Here is my take at the problem: http://smrt.is-a-geek.org/codeblocks/patches/dbg/dbg_refactor0022.5.patch
Your patch is better than mine! I test it under WinXP, and it works OK.

Also, thegdb 7.3 problem  question about exit the debugee when debugging (http://forums.codeblocks.org/index.php/topic,15074.msg100825.html#msg100825) is also solved. thank you!
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on August 14, 2011, 10:37:48 am
/topic,15074.msg100825.html#msg100825]question about exit the debugee when debugging[/url] is also solved. thank you!
Guys, can you explain shortly why for both of you there are modifications in the wxScintilla component required? This doesn't sound obvious and honestly should be avoided as this would surely introduce side-effects.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on August 14, 2011, 10:55:50 am
/topic,15074.msg100825.html#msg100825]question about exit the debugee when debugging[/url] is also solved. thank you!
Guys, can you explain shortly why for both of you there are modifications in the wxScintilla component required? This doesn't sound obvious and honestly should be avoided as this would surely introduce side-effects.
1,
gdb 7.3 exit issue is solved in rev Revision: 7378
Quote
Author: tpetrov
Date: 2011-8-14 8:19:54
Message:
* debugger_branch: fix program exit detection, when using gdb 7.3;

-------------------------------
M : /branches/wxpropgrid_debugger/src/plugins/debuggergdb/gdb_driver.cpp  

2, modify the scintilla code is is try to add a feature that when debugging, hold on the CTRL key, then the mouse hover on a variable will show the debugger tip value.




Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on August 14, 2011, 11:08:52 am
2, modify the scintilla code is is try to add a feature that when debugging, hold on the CTRL key, then the mouse hover on a variable will show the debugger tip value.
This I understood, but why can't this be done without modifying the wxScintilla component?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on August 14, 2011, 11:28:21 am
Because scintilla on windows is not sending the dwell start event if the control or other key is pressed.
I don't know why it doesn't happen on linux, but I see no side effects here. Time will tell.

This is the discussion of Ollydbg with one of the Scintilla devs: http://groups.google.com/group/scintilla-interest/browse_thread/thread/7d109d6e9c6a18f5/700a7871969920da?lnk=gst&q=dwell#700a7871969920da

p.s. there seem to be more problems with the gdb 7.3...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on October 11, 2011, 12:11:14 am
On Topic: I should probably just read the thread/code, but do you have a cliff notes version of the status of your work on the debugger API, oBFus? (May have some free time to think about the python debugger again in coming months)
dmoore (and others of course):
I've almost finished the switch from raw pointer/references to cb::shared_ptr, only the watches are to be converted (will do it this week, hopefully).
Can you look at the API for some missing bits are things that you don't like?

After I'm finished with the watches I plan to add 'Supported features API', so different plugins can advertise what they support or doesn't support.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: dmoore on October 12, 2011, 10:57:34 pm
oBFusCATed: That sounds good. I wil try to take a look in the next couple of weeks. Unfortunately, v.busy atm.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: tomjnx on October 19, 2011, 11:55:31 am
ParseOutput expects to get debugger output line-wise - however the cbTextInputStream does not really guarantee ReadLine to always return a full line. Not being able to read does not mean we are at the end of a line, it could also be that the sending process hasn't written the remainder of the line or the operating system hasn't caught up getting everything to the receiving process. I haven't seen this problem under linux, but on quite a few windows machines it happens occasionally.

If we can no longer read but haven't seen an EOL, we need to buffer the already read characters, return an empty line, and continue on the next call. The attached patch fixes the problem for me.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on October 19, 2011, 12:46:16 pm
Hm, OK, I'll give it a try, but I'm mostly on windows.

Edit: replace windows with linux...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on October 19, 2011, 02:14:18 pm
Hm, OK, I'll give it a try, but I'm mostly on windows.
Please, be very careful with that one. It changes a very sensitive core component of C::B. Basically all elements using PipedProcess will be affected and change it's behaviour.

Also, I don't understand why this:
Code
if (EatEOL(c)) {
  wxString line;
  line.swap(m_line);
  return line;
}
...is needed instead of this:
Code
if (EatEOL(c))
  return m_line;

...and why in the end instead of this:
Code
return wxString();
...not this is used:
Code
return wxEmptyString;
(...which would read better...)

Also, what is a test case to reproduce the actual issue? Because I never had such and I don't know anybody else suffering from this implementation.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on October 19, 2011, 02:39:33 pm
Please, be very careful with that one. It changes a very sensitive core component of C::B. Basically all elements using PipedProcess will be affected and change it's behaviour.
Yes, I know, I've tried to modify this part already, as you know I've failed miserably :(

Also, I don't understand why this:
Code
if (EatEOL(c)) {
  wxString line;
  line.swap(m_line);
  return line;
}
...
This is the same as:
Code
wxString s=m_line;
m_line.clear();
return s;
But it is faster, it is pretty standard c++ trick :)

Also, what is a test case to reproduce the actual issue? Because I never had such and I don't know anybody else suffering from this implementation.
+1
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on October 19, 2011, 03:01:47 pm
This is the same as:
Code
wxString s=m_line;
m_line.clear();
return s;
But it is faster, it is pretty standard c++ trick :)
Ah - I missed that the this is a member variable now that needs to be cleared. OK.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: tomjnx on October 24, 2011, 03:03:06 pm
Also, what is a test case to reproduce the actual issue? Because I never had such and I don't know anybody else suffering from this implementation.

Sorry, I don't have an easy testcase. I'd have to send you my computer 8-)

I have one machine where it happens pretty much always (Win XP), two where it happens occasionally (W2K), and quite a few where it never happens.

And it only happens if the debugger writes lots of output, which is seldom enough.

Under Linux, you're not going to see this. Because any debugger output less than 4kBytes (and provided the debugger only calls write for full lines, haven't checked whether gdb does it), is guaranteed by the OS to hit the receiver process atomically.

What are the intended semantics of cbTextInputStream::ReadLine()? What should happen if the writing process only writes part of a line (i.e. characters without terminating newline)? Should ReadLine() block? Should it return that part of the line even if it is not a full line? (and return the rest of the line should the writing process decide to continue the line in a second call to ReadLine(), leaving the caller with no way to determine where the real line ends were)?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on November 01, 2011, 03:25:26 pm
(peanut gallery chiming in, FWIW)
Can you get the debugger to write lots of output by opening a disassembly window, selecting mixed mode, and stepping through a large module, or possibly back-and-forth between two different large modules, while trying to see if your problem occurs?  The stepping can probably be in the normal source window, I think the disassembly window will still be (re-)populated in background.

(A large enough module should also be able to exceed the mentioned 4K size on linux, depending on how much disassembly changed since I was in in it...) 

Of course, if you need lots of output withOUT a line-ending present, that probably won't do, as the disassembly will most likely have line-endings fairly often...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on November 01, 2011, 03:48:26 pm
svn wxpropgrid_debugger branch R7550 fails to build:
        SqPlus::SQClassDef<wxArrayString>("wxArrayString").
                emptyCtor().
                func(&wxArrayString::Add, "Add").
                func(&wxArrayString::Clear, "Clear").
//                func(&wxArrayString::Index, "Index").
                staticFuncVarArgs(&wxArrayString_Index, "Index", "*").
                func(&wxArrayString::GetCount, "GetCount").
                func(&wxArrayString::Item, "Item");
C:\dev\codeblocks\svn_dbgbranch_on20111101\src\sdk\scripting\bindings\sc_wxtypes.cpp:251: error: no matching function for call to 'SqPlus::SQClassDef<wxArrayString>::func(<unresolved overloaded function type>, const char [5])'

Same problem exists in trunk R7550 retrieved shortly before debugger branch.

Additionally, debugger branch also seems to be missing parenthesis when build attempted with wx 2.9(.2)

sdk\cbplugin.cpp:640-644
Code
    #if wxCHECK_VERSION(2, 9, 0)
    Manager::Get()->GetLogManager()->DebugLog(F(_("Switching layout to \"%s\""), name.wx_str())); <<<==== I added final paren here
    #else
    Manager::Get()->GetLogManager()->DebugLog(F(_("Switching layout to \"%s\""), name.c_str()));
    #endif
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on November 01, 2011, 04:37:36 pm
Debugger branch is not ported to wx2.9, sorry.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on November 01, 2011, 11:44:29 pm
The missing brace is fixed in the branch, thanks.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Pecan on November 14, 2011, 04:21:39 pm
svn build  rev 7587 (2011-11-12 18:16:49)   gcc 4.3.1 Windows/unicode - 32 bit

At compileroptionsdlg.cpp statement 2293
Code
    // compiler set buttons
    if (!m_pProject)
    {
        en = !data; // global options selected

m_pProject is always 0x0. If I place the following before 2293
Code
    if (!m_pProject) asm("int3"); /*trap*/

the trap never occurs whether there's a project loaded or not.

The old code used to read:
Code
    // compiler set buttons
    if (XRCCTRL(*this, "btnAddCompiler", wxButton)) // only if exist
    {
        en = !data; // global options selected

Something is strange here...
http://dl.dropbox.com/u/46870262/ScreenShot00749.jpg
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on November 14, 2011, 04:37:23 pm
Here is the exact commit: http://svn.berlios.de/wsvn/codeblocks/trunk/src/plugins/compilergcc/compileroptionsdlg.cpp?op=diff&rev=6084&peg=7590

It is in trunk and have nothing to do with the branch. I guess Morten could tell you more about it.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on November 14, 2011, 04:40:02 pm
Code
    // compiler set buttons
    if (XRCCTRL(*this, "btnAddCompiler", wxButton)) // only if exist
    {
        en = !data; // global options selected
I saw that, too already. IMHO the old code was a hack to differ between the dialog with the global compiler options and the dialog local (project/target based) options. This was implemented rather bad, obviously... ;-)

EDIT: My intention was to directly check for a valid m_pProject pointer, which means, a project is present (not valid for the global compiler dialog). It doesn't seem to work though... :-(
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on November 14, 2011, 09:20:56 pm
The compileroptionsdialog is used in two places:
one time as panel from "Settings -> Compiler and debugger" (compilergcc.cpp:548), without a project,
and the other time if "Project -> Build options" is clicked (compilergcc.cpp:526), with a project of course.
So different controls are needed and therefore shown.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on November 14, 2011, 09:28:35 pm
Code
    // compiler set buttons
    if (XRCCTRL(*this, "btnAddCompiler", wxButton)) // only if exist
    {
        en = !data; // global options selected
I saw that, too already. IMHO the old code was a hack to differ between the dialog with the global compiler options and the dialog local (project/target based) options. This was implemented rather bad, obviously... ;-)

EDIT: My intention was to directly check for a valid m_pProject pointer, which means, a project is present (not valid for the global compiler dialog). It doesn't seem to work though... :-(
It seems to works correctly here.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on November 15, 2011, 09:25:20 am
EDIT: My intention was to directly check for a valid m_pProject pointer, which means, a project is present (not valid for the global compiler dialog). It doesn't seem to work though... :-(
[...]
It seems to works correctly here.
That would be good news... I can't try myself atm...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on December 12, 2011, 11:01:19 am
I assume the latest changes in the debugger branch broke the batch build feature of C::B. The effect is strange: The wxScintilla control cannot be created and C::B crashes.

The crash log points to:
DebuggerManager -> SetInterfaceFactory -> cbDebugInterfaceFactory

To reproduce, try to run a batch build like this:
codeblocks --batch-build-notify --no-batch-window-close --target=All --build WhatEver.workspace

Does it happen for you, too?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on December 12, 2011, 12:05:46 pm
To reproduce, try to run a batch build like this:
Here comes a backtrace:
Code
sdk/wxscintilla/src/wxscintilla.cpp:247
sdk/wxscintilla/src/wxscintilla.cpp:1721
src/disassemblydlg.cpp:55
src/debugger_interface_creator.cpp:111
sdk/debuggermanager.cpp:990
src/main.cpp:787
src/main.cpp:702
src/main.cpp:567
src/app.cpp:407
src/app.cpp:641
The pointers to the wxscintilla.cpp and main.cpp source files might not be meaningful, as they differ from the once of the debugger branch.
Title: Cannot stop debugger
Post by: Pecan on December 12, 2011, 05:50:51 pm
I've happened on a situation where the debugger cannot be paused or stopped.

SVN 7631 debugger branch
Here are the steps
1) Load the debugger branch BrowseTracker.cbp
2) Place a trap at stmt 443
Code
// ----------------------------------------------------------------------------
void JumpTracker::OnMenuJumpBack(wxCommandEvent &/*event*/)
// ----------------------------------------------------------------------------
{asm("int3"); /*trap*/
    #if defined(LOGGING)
    LOGIT( _T("JT [%s]"), _T("OnMenuJumpBack"));
    #endif

3) compile without -g and with -s
4) run the debugger with BrowseTracker loaded.
5) load codeblocks.cbp into the debugee
6) click anywhere in a source file, page down two pages and click again
7) click on menu, view, jump, jump back ;the debugee CB will trap.
8) click on debug toolbar "next line"
All but the pause and stop buttons will then disable, but the debugger will forever be "Trying to pause the run in progress"
Code
Debugger log
----------------
Active debugger config: GDB debugger:Default
Building to ensure sources are up-to-date
Selecting target:
default
Adding source dir: C:\Usr\Proj\cbDebug\trunk\src\plugins\contrib\BrowseTracker\
Adding source dir: C:\Usr\Proj\cbDebug\trunk\src\plugins\contrib\BrowseTracker\
Adding file: ..\..\..\devel\codeblocks.exe
Changing directory to: C:/Usr/Proj/cbDebug/trunk/src/plugins/contrib/BrowseTracker/.
Starting debugger: gdb.exe -nx -fullname  -quiet -args ../../../devel/codeblocks.exe
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb (GDB) 7.0
Child process PID: 3472
Program received signal SIGTRAP, Trace/breakpoint trap.
In ?? () (C:\Usr\Proj\cbDebug\trunk\src\devel\share\codeblocks\plugins\BrowseTracker.dll)


Debugger(debug) log
-------------------
PATH=.;C:\Usr\Proj\cbDebug\trunk\src\devel;C:\Usr\Proj\wxWidgets2810\lib\gcc_dll;C:\Usr\mingw431\bin;C:\Usr\Proj\ImageCraft\ImageCraft_AVR\trunk\src\output;C:\WINDOWS\system32;C:\WINDOWS;.;c:\usr\bin;c:\usr\bin\subversion\
Command-line: gdb.exe -nx -fullname  -quiet -args ../../../devel/codeblocks.exe
Working dir : C:\Usr\Proj\cbDebug\trunk\src\plugins\contrib\BrowseTracker
> set prompt >>>>>>cb_gdb:
Reading symbols from C:\Usr\Proj\cbDebug\trunk\src\plugins\contrib\BrowseTracker/../../../devel/codeblocks.exe...done.
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb (GDB) 7.0
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
>>>>>>cb_gdb:
> set confirm off
>>>>>>cb_gdb:
> set width 0
>>>>>>cb_gdb:
> set height 0
>>>>>>cb_gdb:
> set breakpoint pending on
>>>>>>cb_gdb:
> set print asm-demangle on
>>>>>>cb_gdb:
> set unwindonsignal on
>>>>>>cb_gdb:
> set print elements -1
>>>>>>cb_gdb:
> set debugevents on
>>>>>>cb_gdb:
> set disassembly-flavor att
>>>>>>cb_gdb:
> catch throw
Catchpoint 1 (throw)
>>>>>>cb_gdb:
> source c:\Usr\Proj\cbDebug\trunk\src\output\share\codeblocks/scripts/stl-views-1.0.3.gdb
>>>>>>cb_gdb:
> directory C:/Usr/Proj/cbDebug/trunk/src/plugins/contrib/BrowseTracker/
>>>>>>cb_gdb:
> set args --debug-log --multiple-instance -na -ns -nd
>>>>>>cb_gdb:
> run
gdb: windows_init_thread_list
[New Thread 3472.0xb54]
a70000.
[New Thread 3472.0xa04]
[New Thread 3472.0x9fc]
[New Thread 3472.0xf84]
[New Thread 3472.0x10f8]
[New Thread 3472.0x458]
[New Thread 3472.0xe58]
[New Thread 3472.0x284]
[New Thread 3472.0x4f0]
[New Thread 3472.0xbac]
[New Thread 3472.0xb7c]
[New Thread 3472.0x15c]
[New Thread 3472.0x137c]
Error: dll starting at 0x76e90000 not found.
Error: dll starting at 0x751c0000 not found.
Error: dll starting at 0x76e90000 not found.
Error: dll starting at 0x76d90000 not found.
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
(... lots of these...)
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
Program received signal SIGTRAP, Trace/breakpoint trap.
0x04c37a8a in ?? () from C:\Usr\Proj\cbDebug\trunk\src\devel\share\codeblocks\plugins\BrowseTracker.dll
Current language:  auto
The current source language is "auto; currently c++".
>>>>>>cb_gdb:
> set debugevents off
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
>>>>>>cb_gdb:
> bt 30
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x28f8a3 in read in psymtab, but not in symtab.)
(...lots and lots of these...)
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
#0  0x04c37a8a in ?? () from C:\Usr\Proj\cbDebug\trunk\src\devel\share\codeblocks\plugins\BrowseTracker.dll
#1  0x0028f8a4 in ?? ()
#2  0x0028f8a4 in ?? ()
#3  0x0028f440 in ?? ()
#4  0x101a398b in wxMenuBase::UpdateUI(wxEvtHandler*) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#5  0x10095099 in wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#6  0x100951bb in wxEvtHandler::SearchDynamicEventTable(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#7  0x100977e6 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#8  0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#9  0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#10 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#11 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#12 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#13 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#14 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#15 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#16 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#17 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#18 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#19 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#20 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#21 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#22 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#23 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#24 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#25 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#26 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#27 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#28 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#29 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
>>>>>>cb_gdb:
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on December 12, 2011, 05:57:10 pm
OK, I'll see what happens.
Is this reproducible with simple console project?

I'm not sure this is the whole log, by the way. There is no log about the stopping events.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Pecan on December 12, 2011, 05:59:59 pm
Here's the "stopping event"

Code
Active debugger config: GDB debugger:Default
Building to ensure sources are up-to-date
Selecting target:
default
Adding source dir: C:\Usr\Proj\cbDebug\trunk\src\plugins\contrib\BrowseTracker\
Adding source dir: C:\Usr\Proj\cbDebug\trunk\src\plugins\contrib\BrowseTracker\
Adding file: ..\..\..\devel\codeblocks.exe
Changing directory to: C:/Usr/Proj/cbDebug/trunk/src/plugins/contrib/BrowseTracker/.
Starting debugger: gdb.exe -nx -fullname  -quiet -args ../../../devel/codeblocks.exe
done
Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Debugger name and version: GNU gdb (GDB) 7.0
Child process PID: 3528
Program received signal SIGTRAP, Trace/breakpoint trap.
In ?? () (C:\Usr\Proj\cbDebug\trunk\src\devel\share\codeblocks\plugins\BrowseTracker.dll)
Trying to pause the running process...
Trying to pause the running process...
Trying to pause the running process...



PATH=.;C:\Usr\Proj\cbDebug\trunk\src\devel;C:\Usr\Proj\wxWidgets2810\lib\gcc_dll;C:\Usr\mingw431\bin;C:\Usr\Proj\ImageCraft\ImageCraft_AVR\trunk\src\output;C:\WINDOWS\system32;C:\WINDOWS;.;c:\usr\bin;c:\usr\bin\subversion\
Command-line: gdb.exe -nx -fullname  -quiet -args ../../../devel/codeblocks.exe
Working dir : C:\Usr\Proj\cbDebug\trunk\src\plugins\contrib\BrowseTracker
> set prompt >>>>>>cb_gdb:
Reading symbols from C:\Usr\Proj\cbDebug\trunk\src\plugins\contrib\BrowseTracker/../../../devel/codeblocks.exe...done.
(gdb) >>>>>>cb_gdb:
> show version
GNU gdb (GDB) 7.0
Copyright (C) 2009 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
and "show warranty" for details.
This GDB was configured as "mingw32".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
>>>>>>cb_gdb:
> set confirm off
>>>>>>cb_gdb:
> set width 0
>>>>>>cb_gdb:
> set height 0
>>>>>>cb_gdb:
> set breakpoint pending on
>>>>>>cb_gdb:
> set print asm-demangle on
>>>>>>cb_gdb:
> set unwindonsignal on
>>>>>>cb_gdb:
> set print elements -1
>>>>>>cb_gdb:
> set debugevents on
>>>>>>cb_gdb:
> set disassembly-flavor att
>>>>>>cb_gdb:
> catch throw
Catchpoint 1 (throw)
>>>>>>cb_gdb:
> source c:\Usr\Proj\cbDebug\trunk\src\output\share\codeblocks/scripts/stl-views-1.0.3.gdb
>>>>>>cb_gdb:
> directory C:/Usr/Proj/cbDebug/trunk/src/plugins/contrib/BrowseTracker/
>>>>>>cb_gdb:
> set args --debug-log --multiple-instance -na -ns -nd
>>>>>>cb_gdb:
> run
gdb: windows_init_thread_list
[New Thread 3528.0x258]
d=600, DBG_CONTINUE);
[New Thread 3528.0xcd0]
[New Thread 3528.0x11d8]
[New Thread 3528.0xe14]
[New Thread 3528.0xaf8]
[New Thread 3528.0x1220]
[New Thread 3528.0xb5c]
[New Thread 3528.0x5bc]
[New Thread 3528.0xe58]
[New Thread 3528.0xeb4]
[New Thread 3528.0xc7c]
[New Thread 3528.0x204]
[New Thread 3528.0x12f4]
Error: dll starting at 0x76e90000 not found.
Error: dll starting at 0x751c0000 not found.
Error: dll starting at 0x76e90000 not found.
Error: dll starting at 0x76d90000 not found.
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
[New Thread 3528.0x10bc]
Program received signal SIGTRAP, Trace/breakpoint trap.
0x04c37a8a in ?? () from C:\Usr\Proj\cbDebug\trunk\src\devel\share\codeblocks\plugins\BrowseTracker.dll
Current language:  auto
The current source language is "auto; currently c++".
>>>>>>cb_gdb:
> set debugevents off
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
>>>>>>cb_gdb:
> bt 30
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
(... many duplicate lines removed...)
warning: (Internal error: pc 0x100977a6 in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
#0  0x04c37a8a in ?? () from C:\Usr\Proj\cbDebug\trunk\src\devel\share\codeblocks\plugins\BrowseTracker.dll
#1  0x0028f8a4 in ?? ()
#2  0x0028f8a4 in ?? ()
#3  0x0028f440 in ?? ()
#4  0x101a398b in wxMenuBase::UpdateUI(wxEvtHandler*) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#5  0x10095099 in wxEvtHandler::ProcessEventIfMatches(wxEventTableEntryBase const&, wxEvtHandler*, wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#6  0x100951bb in wxEvtHandler::SearchDynamicEventTable(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#7  0x100977e6 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#8  0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#9  0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#10 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#11 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#12 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#13 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#14 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#15 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#16 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#17 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#18 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#19 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#20 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#21 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#22 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#23 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#24 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#25 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#26 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#27 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#28 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
#29 0x100977a7 in wxEvtHandler::ProcessEvent(wxEvent&) () from C:\Usr\Proj\cbDebug\trunk\src\devel\wxmsw28u_gcc_custom.dll
>>>>>>cb_gdb:
> next
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
warning: (Internal error: pc 0x4c37a8a in read in psymtab, but not in symtab.)
Cannot find bounds of current function
>>>>>>cb_gdb:


With simple "Hello World" the program steps once and runs to end.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on December 13, 2011, 07:47:00 pm
Does it happen for you, too?
Yes, it does.

Here is a patch that fixes it. Is it OK to commit it?

Explanation:
Before my commit it was working, because CreateToolbars() was called before creating the debugger related windows. Now it is called after that.
And for some strange reason CreateToolbars is loading the resources for the second time.

Code
Index: src/src/app.cpp
===================================================================
--- src/src/app.cpp     (revision 7634)
+++ src/src/app.cpp     (working copy)
@@ -525,12 +525,15 @@
         // set safe-mode appropriately
         PluginManager::SetSafeMode(m_SafeMode);
 
-        if(!m_Batch && m_Script.IsEmpty() && !InitXRCStuff())
+        if(!m_Batch && m_Script.IsEmpty())
         {
            // wsSafeShowMessage(_T("Fatal error"), _T("Initialisation of resources failed."));
             return false;
         }
 
+        if (!InitXRCStuff())
+            return false;
+
         InitLocale();
 
         if(m_DDE && !m_Batch && Manager::Get()->GetConfigManager(_T("app"))->ReadBool(_T("/environment/use_ipc"), true))
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on December 13, 2011, 08:19:04 pm
Here is a patch that fixes it. Is it OK to commit it?
To be honest its strange to see why this patch should work?! But if it does and you are sure to have found the reason, feel free to go ahead. My worries are that the batch window might need the XRC stuff to be initialised (I am not sure about that) so it might have some side effects... (remember that you can enable plugins at will in batch mode) - I'll try though... If the XRC stuff is really not needed in batch mode (Yiannis?!) than it would actually be a good thing not to initialise it, as this safes time.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on December 13, 2011, 08:55:58 pm
I did not test the patch, but if I see it correctly, OnInit will always return false, if we are not in batch-build mode and do not give a script to execute on commandline.
This should be true in most cases, where C::B is used "normally".
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on December 13, 2011, 09:51:31 pm
Jens, I'm not sure I understand what you've just said/written... :(
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on December 13, 2011, 10:31:23 pm
Jens, I'm not sure I understand what you've just said/written... :(
On normal startup of C::B m_Batch is false and m_Script is empty and with your patch, OnInit() will always return false and therefore end the application.

Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on December 14, 2011, 12:02:21 am
Argh, you're right.

What about this version then:

Code
Index: C:/dev/cb_dev/debugger1/src/src/app.cpp
===================================================================
--- C:/dev/cb_dev/debugger1/src/src/app.cpp (revision 7633)
+++ C:/dev/cb_dev/debugger1/src/src/app.cpp (working copy)
@@ -524,8 +524,7 @@
 
         // set safe-mode appropriately
         PluginManager::SetSafeMode(m_SafeMode);
-
-        if(!m_Batch && m_Script.IsEmpty() && !InitXRCStuff())
+        if(!InitXRCStuff() && !m_Batch && m_Script.IsEmpty())
         {
            // wsSafeShowMessage(_T("Fatal error"), _T("Initialisation of resources failed."));
             return false;


I've search the svn history and it seems that the check was added on purpose by Thomas in r2706.
Thomas any comments on this?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on December 14, 2011, 08:51:39 am
This one should work, the only difference is, that it calls InitXRCStuff() also in batch-mode.
If that's really needed, it has to be done this way.

My worries are that the batch window might need the XRC stuff to be initialised (I am not sure about that) so it might have some side effects... (remember that you can enable plugins at will in batch mode) - I'll try though... If the XRC stuff is really not needed in batch mode (Yiannis?!) than it would actually be a good thing not to initialise it, as this safes time.
In former version InitXRCStuff() was not called in batch mode, now (we the new patch) it is, so we might get more overhead than needed.
Maybe it would be better to change the new code that leads to the crash in a matter, that it is not needed, but we should check how much time (and memory) it really uses and if it makes a measurable difference.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on December 14, 2011, 09:48:07 am
I doubt you'll see a difference, because the resource.zip file is loaded always in the CreateToolbars method.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on December 18, 2011, 05:12:07 pm
Another thing I noticed while working on the 64 bit port of C::B:

You make heavy use of the stand-alone version of the wxPropGrid stuff. In fact, sooner or later it makes probably sense to use the wxPropGrid that ships with wx 2.9.x itself (as you'll need 2.9.x anyways for the compilation in 64 bit). I already did a lot of hacking to be compatible with both: the stand-alone and the wx integrated version. No I see a show-stopper which is the macro handling to register a wxPropGridEditor.

If you have time and nothing else to do ( ;D ;D ;D ) you may want to try to compile against wx 2.9.x. While in trunk this works after a few work-arounds, the debugger branch fails, but only due to the Editor stuff... :-(

Just wanted to make your heads up what will be next the one or other day...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on December 18, 2011, 05:44:02 pm
Vanilla stand alone wxPropGrid and the wxPropGrid in wx2.9 won't work, because I have made some changes.
Search for 'CB Begin' and 'CB end' comments in the source to see what have been changed.

Is it possible to use wx2.9+our version of wxPropGrid?

p.s. I was planning to submit some patches for wxPropGrid, but I postponed the task because of laziness...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on December 18, 2011, 08:04:29 pm
Is it possible to use wx2.9+our version of wxPropGrid?
I think so, yes - but for distribution we need to do something like with wxScintilla and (more important) make sure the include folders are correct, thus what uses wxPropGrid searches first in the C::B SDK. The latter was the reason for me to use the WX version. A lot of C::B code would first include the wxPropGrid sources from WX. :(
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on December 18, 2011, 11:35:46 pm
I was planning to submit the patches to upstream, but I've not done so.
Also I'm not sure what is the status of wxpropgrid stand alone anymore, probably I should talk to wx people.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on December 29, 2011, 10:23:43 pm
If you have time and nothing else to do ( ;D ;D ;D ) you may want to try to compile against wx 2.9.x. While in trunk this works after a few work-arounds, the debugger branch fails, but only due to the Editor stuff... :-(
Patches? I've given it 15minutes to try to make it compile but the changes are too much for me.
Do you use the normal codeblocks.cbp file or you're using the -wx29.cbp file? I'm try to compile it on linux and there is no -wx29.cbp file.
Also I've tried to hack the includes, but it didn't work, because of the `wx-config`stuff - it always takes precedence.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on December 30, 2011, 07:47:20 am
Patches? I've given it 15minutes to try to make it compile but the changes are too much for me.
Do you use the normal codeblocks.cbp file or you're using the -wx29.cbp file? I'm try to compile it on linux and there is no -wx29.cbp file.
Too many of them and they are still WIP. I thought of creating another branch, so far I am using a heavily patched source tree with an own project file (the one with -wx29.cbp won't compile for 64 bit).
 
Also I've tried to hack the includes, but it didn't work, because of the `wx-config`stuff - it always takes precedence.
Well if should work if you play with the compiler/linker policies, even if you are using a script.

I don't know how we should handle it best... a 64 bit branch of the debugger branch / of trunk???
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on December 30, 2011, 09:57:12 am
Too many of them and they are still WIP. I thought of creating another branch, so far I am using a heavily patched source tree with an own project file (the one with -wx29.cbp won't compile for 64 bit).
OK.
 
Well if should work if you play with the compiler/linker policies, even if you are using a script.
The problem is that the `wx-config --cflags` is in other compiler settings and they are always used before the include search paths.

I don't know how we should handle it best... a 64 bit branch of the debugger branch / of trunk???
Please don't do a branch of the branch, it will be a nightmare...
The best thing you can do is to fix trunk and then I'll try to fix the branch.
Maybe you can commit in trunk directly, so more people could test your changes.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on December 30, 2011, 06:15:02 pm
Also I'm not sure what is the status of wxpropgrid stand alone anymore, probably I should talk to wx people.
According to this:

http://sourceforge.net/projects/wxpropgrid/forums/forum/452254/topic/3959996

It seems the best way is to make use of the wx integrated version of wxPropGrid on the long run. Also, according to the SVN logs there seems not much active development on the stand-alone version of wxPropGrid recently.

Maybe you can contact the author of that component asking what to do best. I did a lot ugly #if wxCHECK_VERSION(2, 9, 0), but finally the wxPGRegisterEditorClass macro breaks it completely. I don't see a good way to overcome this. If you want to try, I can provide you with the wx 2.9.x project file I have / use which does not use the 64 bit compiler (I have three: one for wx 2.9.x/32 bit; one for wx 2.9.x/64 bit... and the "legacy" for wx 2.8.x/32 bit).
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on December 30, 2011, 06:57:13 pm
Don't worry for the editor staff, I think I've fixed it.
Testing it on wx2.9 crashes cb, when adding a watch and I don't have debug version of wx2.9, so I cannot test it much.
But I'll check if wx2.8 still works correctly and I'll commit.
Or if you prefer I can give you a patch to test it.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on December 30, 2011, 07:08:23 pm
Here is the patch: http://smrt.is-a-geek.org/codeblocks/patches/dbg/cb_dbg_wx29.patch

Please test it on windows and tell me if it compiles and hopefully runs correctly.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on December 30, 2011, 07:14:41 pm
Morten:
Are you sure commit r7651 is OK?
I don't think this commit was needed in trunk, because the index is correctly set there.
Probably you wanted to backport the stepinto bug fixed in r7638? (http://svn.berlios.de/wsvn/codeblocks?op=comp&compare[]=%2F@7637&compare[]=%2F@7638)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on December 30, 2011, 08:12:52 pm
Probably you wanted to backport the stepinto bug fixed in r7638? (http://svn.berlios.de/wsvn/codeblocks?op=comp&compare[]=%2F@7637&compare[]=%2F@7638)
Yes, that's what I had in mind... did I pick the wrong one??? (Reverting now...)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on December 30, 2011, 08:21:56 pm
You can commit the other it is one liner :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 02, 2012, 07:22:50 pm
Feature wish:
I have 2 debugger configurations: One for 32 bit and one for 64 bit. Switching between those would be easier if the toolbar would offer a drop-down box to select the currently active config on-the-fly if.

For now, I always need to enter the debugger settings, even though I have two targets (32 bit and 64 bit) in one project.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 02, 2012, 08:46:53 pm
Why don't you set the correct debugger config in the toolchain executables for your 32bit and 64bit compilers and then use Debug->Active debuggers->Target's default?

Do you know that you can have multiple configs for one debugger plugin and you can switch them in Debug->Active debuggers?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 03, 2012, 07:53:21 am
Do you know that you can have multiple configs for one debugger plugin and you can switch them in Debug->Active debuggers?
No. ::) :P

Why don't you set the correct debugger config in the toolchain executables for your 32bit and 64bit compilers and then use Debug->Active debuggers->Target's default?
Where do I set the preferred debugger for a target?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 03, 2012, 09:09:47 am
In the Settings -> Compiler -> Toolchain executable -> Debugger
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 03, 2012, 10:10:06 am
In the Settings -> Compiler -> Toolchain executable -> Debugger
Yes, I know that. But this is global and not per-target. I guess I mis-understood.

But the option from the menu is just fine...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 03, 2012, 10:26:47 am
If you have two different compiler for two different targets it will use the appropriate debugger configuration.

Probably we can add some options for this per target, but I'm not sure what is needed, so you can help me in this regard :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 03, 2012, 10:47:44 am
Probably we can add some options for this per target, but I'm not sure what is needed, so you can help me in this regard :)
I don't think so...
But the option from the menu is just fine...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on January 04, 2012, 12:27:16 am
The branch crashes for me in batchbuild mode (on Linux and Windows).
When trying to create m_disassemblyDialog from inside  DebuggerManager::SetInterfaceFactory wxScintilla stops with "Could not create a new wxControl instance.".

Too late to dig into it later at the moment.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 04, 2012, 01:01:36 am
Yes, we discussed it before and there was no approved solution.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on January 04, 2012, 06:41:05 am
Yes, we discussed it before and there was no approved solution.
Do we really need to initialize debugging-stuff in batchbuild mode ?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 04, 2012, 09:05:22 am
The thing is that the code assumes that the debugging windows are correctly created and never checks for null pointers.
I can add the checks but I prefer not to do so.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 04, 2012, 10:19:09 am
I've merged the debugger branch with trunk and adjusted a few more wx 2.9.x compatibility things. Feel free to compile the C::B core of the branch using the project file "CodeBlocks_wx29.cbp" and "update29.bat" (also in SVN).

The same applies to trunk for those who want to try wx 2.9.x progress.

BTW: If you are compiling wx 2.9.x, make sure to switch off "WXWIN_COMPATIBILITY_2_6" and "WXWIN_COMPATIBILITY_2_8" when compiling wxWidgets 2.9.x from sources.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 04, 2012, 03:57:35 pm
Morten:
"#define wxPG_COMPATIBILITY_1_2_0 0" breaks the build of wxsmith.
When committing please ensure that the contrib plugins build, too, because I'm using the branch as my main install!
Also this change should have been made in trunk, not in the branch!
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 04, 2012, 05:27:14 pm
"#define wxPG_COMPATIBILITY_1_2_0 0" breaks the build of wxsmith.
Not for me... I'll try though...

Also this change should have been made in trunk, not in the branch!
Why? wxPropGrid is already modified by you in the branch and differs therefore from trunk IMHO... I maybe wrong though...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 04, 2012, 05:49:56 pm
Not for me... I'll try though...
There is a missing wxIsIdOk or something like that when the compatibility is off.

Why? wxPropGrid is already modified by you in the branch and differs therefore from trunk IMHO... I maybe wrong though...
Because this helps porting the code using wxpropgrid to wx2.9 a lot, and so commits changing wxsmith will fail to compile early if this change is in trunk.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 04, 2012, 05:58:48 pm
There is a missing wxIsIdOk or something like that when the compatibility is off.
Ah! yes, I had fixed this already... Seems I forgot to commit a file... I'll sort it out... Sorry. :-[
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 04, 2012, 06:06:12 pm
Ah! yes, I had fixed this already... Seems I forgot to commit a file... I'll sort it out... Sorry. :-[
Could you try again, please. The issue here is, that I also manage the wxSmith branch which has a lot more wxSmith related changes / patches... man - we should really consider to finally merge at least this branch into trunk.

Concerning wxPropGrid. I'll try to back-port the whole wxPropGrid stuff into trunk. Then both should be in sync for this component. Would that be OK for you?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 04, 2012, 06:15:04 pm
Don't worry, I've not compiled it. But I didn't commit the change because I didn't have the time to fix trunk.

Yes, syncing wxPropGrid is OK with me.

About the merging of the branch,
I have probably one last API breaking change (it will be committed this week) and I think I'll be ready for a merge.
My current target is the end of January. Stay tuned :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 05, 2012, 09:40:51 pm
Ok, I've committed the API change (maybe the last major one) and a fix for the batch mode, please test and report if there are any problems.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on January 05, 2012, 10:07:52 pm
Ah! yes, I had fixed this already... Seems I forgot to commit a file... I'll sort it out... Sorry. :-[
Could you try again, please. The issue here is, that I also manage the wxSmith branch which has a lot more wxSmith related changes / patches... man - we should really consider to finally merge at least this branch into trunk.

Can we wait with a merge, until the linux and windows build fixes (and directory layout changes) are made ?
I work on it, but sometimes my family (and my boss) need my time also.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 05, 2012, 10:25:08 pm
But then you'll have to do the job twice, I guess.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on January 05, 2012, 10:52:21 pm
But then you'll have to do the job twice, I guess.
I do it in the wxsmith-branch, and if it is ready, it can be merged back into trunk.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 06, 2012, 06:22:02 am
Can we wait with a merge, until the linux and windows build fixes (and directory layout changes) are made ?
Yes, sure - I won't do it overnight. ;-) Although I wonder what is still pending. It looks pretty good now.

I have (however) prepared to merge the wxPropGrid changes from the debugger branch into trunk. This will than also land (sooner or later) in the wxsmith branch.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 13, 2012, 05:36:43 pm
I had the following issue several times now:
While debugging, I pressed "Next" several times to debug step-by-step and suddenly all debugger buttons are greyed out, except the "Pause " and "Stop". But hitting these does nothing. I have to kill the debugger (notice that killing the debugger's debuggee does nothing, too) to get C::B back to work.
In the debuggers debug log I see:
Code
[debug]> next
[debug]Cannot find bounds of current function
[debug]>>>>>>cb_gdb:

Trying to pause the running process...
And that's basically it. Even if hitting the "Stop" button several times.
What's causing this? Anybody here experiencing the same?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 13, 2012, 05:43:14 pm
Do you have the full log?
Do you have a 100% reproduction case?
My guess is broken GDB/Debug info and also it is caused by not well parsed output from "next".
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 13, 2012, 08:09:45 pm
Do you have the full log?
That *is* the full log. Everything before is related to the last frame/debug info being shown.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 13, 2012, 09:39:54 pm
Test case?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 14, 2012, 03:11:10 pm
Test case?
I didn't find one yet... let me further investigate.

Another one: Concerning the issue that I cannot see the triangle: It is related to the settings! When I run a clean instance of C::B I see the triangle. "Re-installing" my old config makes the triangle go away. Must be either something with the layouts or editor settings... I'll investigate, too.

But: I got another serious one:
- Create a hello world project
- Set a BP
- Goto editor settings
- Don't change anything, but quit the dialog wit "OK"
- Try to remove (toggle) the BP -> does not work!!!
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 14, 2012, 03:16:15 pm
I didn't find one yet... let me further investigate.
Got one!
- Create a hello world project
- Set a BP in the first line in "main".
- Step though the code using F7
- After a few steps I come to that point.

Here is the log:
Code
[debug]>>>>>>cb_gdb:

At c:\users\morten\desktop\mycon\main.cpp:7

[debug]> set debugevents off
[debug]>>>>>>cb_gdb:
[debug]> next
[debug]c:\users\morten\desktop\mycon\main.cpp:8:99:beg:0x401342
[debug]>>>>>>cb_gdb:

At c:\users\morten\desktop\mycon\main.cpp:8

[debug]> next
[debug]c:\users\morten\desktop\mycon\main.cpp:9:114:beg:0x401347
[debug]>>>>>>cb_gdb:

At c:\users\morten\desktop\mycon\main.cpp:9

[debug]> next
[debug]250 ../mingw/crt1.c: No such file or directory.
[debug]__mingw_CRTStartup () at ../mingw/crt1.c:250
[debug] in ../mingw/crt1.c
[debug]>>>>>>cb_gdb:

Trying to pause the running process...
Trying to pause the running process...
Trying to pause the running process...

Note that "Trying to pause the running process..." comes from trying to press pause or stop. And also notice that I hit far more on "Step" than shown in the log...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 14, 2012, 04:17:01 pm
But: I got another serious one:
- Create a hello world project
- Set a BP
- Goto editor settings
- Don't change anything, but quit the dialog wit "OK"
- Try to remove (toggle) the BP -> does not work!!!

This is caused by
1. cbEditor::SaveFoldState() calling cbEditor::OnEditorModified
2 which then calls debugger->EditorLinesAddedOrRemoved,
3. which shifts the breakpoints after the end of the file.

I'm not really sure what should we do, so any suggestions are welcome.
By the way this is broken in trunk, too and I guess it has been broken for years.

I guess this easiest thing is to hack it with some kind of m_noBreakpointShift flag, but I don't want to do it this way. I want a proper fix.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on January 15, 2012, 01:56:06 am
This is caused by
1. cbEditor::SaveFoldState() calling cbEditor::OnEditorModified
2 which then calls debugger->EditorLinesAddedOrRemoved,
3. which shifts the breakpoints after the end of the file.

Can you please test the attached patch ?
It prevents the event-connection if the dummy editor for the fold-backup is created.
So no line-added-event is thrown for the backup editor and therefore the bp's get not shifted.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 17, 2012, 08:34:38 am
Can you please test the attached patch ?
Works here. I think that's way better than before, please commit. ;-)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 17, 2012, 08:38:59 am
Another one:
- Start C::B (do not have anything opened before)
- Create a console app using the wizard, select only debug target
- Once created, place a BP in the "cout << " line
- Hit The "Debug" button from the tool bar.
- For me, GDB does not run the debuggee and I cannot stop the debugger until I kill it from the task manager
--> Note: The "build before debug" is off, so there is no executable! But it should not fail like that.

The log:
[debug]Command-line: C:\Devel\GCC46TDM\bin\gdb.exe -nx -fullname  -quiet  -args 粔"冠ࠇ
[debug]Working dir : C:\DOKUME~1\Morten\Desktop\MYCon

Starting debugger: C:\Devel\GCC46TDM\bin\gdb.exe -nx -fullname  -quiet  -args 粔"冠ࠇ
done

[debug]> set prompt >>>>>>cb_gdb:

Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints

[debug]????: No such file or directory.
[debug](gdb) >>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (GDB) 7.3
[debug]Copyright (C) 2011 Free Software Foundation, Inc.
[debug]License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[debug]This is free software: you are free to change and redistribute it.
[debug]There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
[debug]and "show warranty" for details.
[debug]This GDB was configured as "mingw32".
[debug]For bug reporting instructions, please see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]>>>>>>cb_gdb:
[debug]> set confirm off

Debugger name and version: GNU gdb (GDB) 7.3

[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 0
[debug]>>>>>>cb_gdb:
[debug]> set debugevents on
[debug]>>>>>>cb_gdb:
[debug]> set new-console on
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor att
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]No symbol table is loaded.  Use the "file" command.
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> source C:\Devel\CodeBlocks\share\codeblocks/scripts/stl-views-1.0.3.gdb
[debug]>>>>>>cb_gdb:
[debug]> directory C:/DOKUME~1/Morten/Desktop/MYCon/
[debug]>>>>>>cb_gdb:
[debug]> break "C:/Dokumente und Einstellungen/Morten/Desktop/MYCon/main.cpp:7"
[debug]No symbol table is loaded.  Use the "file" command.
[debug]Breakpoint 2 ("C:/Dokumente und Einstellungen/Morten/Desktop/MYCon/main.cpp:7) pending.
[debug]>>>>>>cb_gdb:
[debug]> run
[debug]No executable specified, use `target exec'.
[debug]>>>>>>cb_gdb:


Notice that the strange Chinese characters "-args 粔"冠ࠇ" are really there.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 17, 2012, 09:36:04 am
Can you try this patch and then tell me if it works:
Code
Index: src/plugins/debuggergdb/gdb_commands.h
===================================================================
--- src/plugins/debuggergdb/gdb_commands.h      (revision 7700)
+++ src/plugins/debuggergdb/gdb_commands.h      (working copy)
@@ -681,9 +681,9 @@
             const wxArrayString &lines = GetArrayFromString(output, _T('\n'));
             for (size_t ii = 0; ii < lines.GetCount(); ++ii)
             {
-                if (lines[ii].StartsWith(wxT("No symbol table loaded."))
-                    || lines[ii].StartsWith(wxT("No executable file specified."))
-                    || lines[ii].StartsWith(wxT("No executable specified.")))
+                if (lines[ii].StartsWith(wxT("No symbol table loaded"))
+                    || lines[ii].StartsWith(wxT("No executable file specified"))
+                    || lines[ii].StartsWith(wxT("No executable specified")))
                 {
                     // log this and quit debugging
                     m_pDriver->Log(_("Starting the debuggee failed: ")+lines[ii]);

About the Chinese characters: I don't see any on linux, but I guess something is not initialized correctly, can you try to debug it?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on January 17, 2012, 09:51:57 am
Can you please test the attached patch ?
Works here. I think that's way better than before, please commit. ;-)
To trunk or to debugger-branch ?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 17, 2012, 10:14:22 am
I've tried it on trunk, because the patch didn't apply on the branch.
I prefer the commit to happen in trunk, because the bug happens there, too.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on January 17, 2012, 11:24:59 am
I've tried it on trunk, because the patch didn't apply on the branch.
I prefer the commit to happen in trunk, because the bug happens there, too.
Done in trunk svn r7702 .
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 17, 2012, 02:53:41 pm
Can you try this patch and then tell me if it works:
It works, but the garbage with the Chinese characters is still there. It looks like a wrong/missing  .c_str() .wxstr() to me...
However, the hang is gone. :-)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 17, 2012, 02:59:40 pm
BTW, also notice this line:
[debug]????: No such file or directory.
It comes when trying to read the symbol table from the executable (debuggee) that is not there yet. Maybe you should check for that pattern too (not sure if you do so already).
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 17, 2012, 03:15:20 pm
I don't do it, but I'm not sure if it is possible.

Can you try to debug the Chinese symbols, I can't reproduce it on linux here and I don't know when I'll have time to switch to windows?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on January 17, 2012, 03:25:08 pm
I don't do it, but I'm not sure if it is possible.

Can you try to debug the Chinese symbols, I can't reproduce it on linux here and I don't know when I'll have time to switch to windows?
I just tested, and if the project path has spaces, then it will show some "Unknown Chinese characters".
This is because gdb can not handle path with spaces.

If you do not have spaces in your path, but no exe built, then there is not such Chinese symbols.

The debugger freeze in both cases. I'm testing latest debugger branch nightly build.

PS, you can not set a breakpoint in a file with spaces under gdb(Windows).
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 17, 2012, 03:25:31 pm
Can you try to debug the Chinese symbols, I can't reproduce it on linux here and I don't know when I'll have time to switch to windows?
Yes, I am already at it but face two times another freeze bug (the one reported earlier with "out of function scope")... :-(
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 17, 2012, 03:26:44 pm
PS, you can not set a breakpoint in a file with spaces under gdb(Windows).
This works very well for me if you have set the "GDB workaround in the advanced compiler options.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 17, 2012, 03:30:35 pm
OK - when entering "GDB_driver::GetCommandLine(const wxString& debugger, const wxString& debuggee, const wxString &userArguments)" I see that "debuggee" is exactly "" " (quote, space). This looks pretty weird.

I see in the debug log:
[debug]> output debuggee
[debug](const wxString &) @0x22e200: {
[debug]  <wxStringBase> = {
[debug]    static npos = <optimized out>,
[debug]    m_pchData = 0x17f39544 L"\"\xe920\221\174"
[debug]  }, <No data fields>}>>>>>>cb_gdb:


(I'll update this post if I got news...)

EDIT: UPDATE:

A little earlier (in int DebuggerGDB::DoDebug(bool breakOnEntry)) I see that "path" is "C:\\Dokumente und Einstellungen\\Morten\\Desktop\\MyCon2\\." then after a call to "ConvertToGDBDirectory(path)" it is "C:/DOKUME~1/Morten/Desktop/MyCon2/.". That's OK.

The command line generated in in "GDB_driver::GetCommandLine" uses "-args " ", so the final command line is:
C:\\Devel\\GCC46TDM\\bin\\gdb.exe -nx -fullname  -quiet  -args "
Do you see the trailing single quotation mark? I think that's it. A bug. :-)

-> No closing quotation mark, so the debugger reads garbage!
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on January 17, 2012, 03:34:25 pm
PS, you can not set a breakpoint in a file with spaces under gdb(Windows).
This works very well for me if you have set the "GDB workaround in the advanced compiler options.
I have already have this option checked.
See my log (with spaces)
Code
Debugger name and version: GNU gdb (GDB) 7.4.50.20120117-cvs
...
[debug]>>>>>>cb_gdb:
[debug]> directory E:/code/cb/TEST_C~1/SPACEF~1/hi/
[debug]>>>>>>cb_gdb:>>>>>>cb_gdb:>>>>>>cb_gdb:
[debug]> break "E:/code/cb/test_code/space folder/hi/main.cpp:8"
[debug]Breakpoint 2 at 0x401402: file E:\code\cb\test_code\space folder\hi\main.cpp, line 8.
[debug]>>>>>>cb_gdb:
[debug]> run
[debug]gdb: windows_init_thread_list

Child process PID: 4164

[debug][New Thread 4164.0x1cc]
[debug]Error in re-setting breakpoint 2: Function "E:/code/cb/test_code/space folder/hi/main.cpp:8" not defined.
[debug][Inferior 1 (process 4164) exited normally]
[debug]>>>>>>cb_gdb:

Error in re-setting breakpoint 2: Function "E:/code/cb/test_code/space folder/hi/main.cpp:8" not defined.
[Inferior 1 (process 4164) exited normally]

[debug]> set debugevents off
[debug]>>>>>>cb_gdb:
[debug]> quit

Debugger finished with status 0

Below is path with no space:
Code
Debugger name and version: GNU gdb (GDB) 7.4.50.20120117-cvs
...
[debug]>>>>>>cb_gdb:
[debug]> directory E:/code/cb/test_code/nospace/hi/
[debug]>>>>>>cb_gdb:>>>>>>cb_gdb:>>>>>>cb_gdb:
[debug]> break "E:/code/cb/test_code/space folder/hi/main.cpp:8"
[debug]No source file named E:/code/cb/test_code/space folder/hi/main.cpp.
[debug]Breakpoint 2 ("E:/code/cb/test_code/space folder/hi/main.cpp:8) pending.
[debug]>>>>>>cb_gdb:
[debug]> break "E:/code/cb/test_code/nospace/hi/main.cpp:7"
[debug]Breakpoint 3 at 0x4013de: file E:\code\cb\test_code\nospace\hi\main.cpp, line 7.
[debug]>>>>>>cb_gdb:
[debug]> run
[debug]gdb: windows_init_thread_list

Child process PID: 6040

[debug][New Thread 6040.0xa34]
[debug]Breakpoint 3, main () at E:\code\cb\test_code\nospace\hi\main.cpp:7
[debug]E:\code\cb\test_code\nospace\hi\main.cpp:7:62:beg:0x4013de
[debug]>>>>>>cb_gdb:

At E:\code\cb\test_code\nospace\hi\main.cpp:7

[debug]> set debugevents off
[debug]>>>>>>cb_gdb:
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on January 17, 2012, 03:45:40 pm
Hey, I found a potential issue. :)

I have two project opened.(one have space in path, the other does not), both have main.cpp and I set one breakpoint per file.

I'm debugging the project with no space(active project), but the log shows that the BP in file with space (non active project) are still sent.

You see the second log:
Code
[debug]> break "E:/code/cb/test_code/space folder/hi/main.cpp:8"
[debug]No source file named E:/code/cb/test_code/space folder/hi/main.cpp.
[debug]Breakpoint 2 ("E:/code/cb/test_code/space folder/hi/main.cpp:8) pending.
[debug]>>>>>>cb_gdb:
[debug]> break "E:/code/cb/test_code/nospace/hi/main.cpp:7"
[debug]Breakpoint 3 at 0x4013de: file E:\code\cb\test_code\nospace\hi\main.cpp, line 7.

Maybe, we should give a message or warning on this cases?


Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 17, 2012, 03:50:05 pm
ollydbg: This is not a bug, but a feature. All breakpoints from all projects are sent, this is done in order to be able to debug inside shared libraries.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on January 17, 2012, 03:53:10 pm
ollydbg: This is not a bug, but a feature. All breakpoints from all projects are sent, this is done in order to be able to debug inside shared libraries.
Yes, I see. No need to change anything on this feature. :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 17, 2012, 04:40:34 pm
-> No closing quotation mark, so the debugger reads garbage!
@oBFusCATed: I think I found the reason. Should I commit at will or do you have stuff pending?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 17, 2012, 04:53:42 pm
Can you try this patch and then tell me if it works:
Full stop. This doesn't work completely. It correctly spits out the debuggee could not be found and I could re-start the debugger, but the internal state seems screwed. Because if I hit the "run-debugger" button several times the "build buttons" and everything never gets back and remain greyed. In addition I don't see any output in the debugger console anymore.

I have to re-start C::B to get it back into a normal state. :-(
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 17, 2012, 05:16:56 pm
Morten: About the Chinese chars: If you've tested it and it works, commit at will:) I guess this is related to the additional arguments patch.
Hm, strange. Can you try to debug this, too?

ollydbg: I don't get what is your problem? As far as I know the newly shown windows are not placed by C::B, but by your Explorer.exe.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 17, 2012, 06:17:41 pm
If you've tested it and it works, commit at will:) I guess this is related to the additional arguments patch.
Nope, its not. I've committed.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 17, 2012, 06:25:10 pm
Morten:
Can I ask you to stop committing real changes and style changes in a single commit?
I don't know if you have something that automatically fixes the formatting, but it is pretty hard to look at your commits, because mostly they are full of formatting noise.

BTW: you don't follow your style 100%, because you fix code like "if(!test)", to "if (!test)" or "if ( !test )".
At my current company we have the following rule: "you must not change the formatting of code you're not changing"; which is one pretty good rule.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 17, 2012, 07:56:53 pm
Can I ask you to stop committing real changes and style changes in a single commit?
I think all you need is a good diff tool. The one I use can simply hide "whitespace" changes so you only see what is really changed.

Concerning style: I use an automated astyle run whenever I save a file. My settings are usually consistent and follow the following (in-house company) rules:
1.) After if, for, while follows a space
2.) After the opening and before the closing bracket follows a space only in case a function call is done inside the clause.

I'll try to turn automatic formatting off next time. By default its enabled and I cannot set it "per-project".

BTW: If works even if you use the WEB-SVN:
http://svn.berlios.de/wsvn/codeblocks/branches/wxpropgrid_debugger/src/plugins/debuggergdb/debuggergdb.cpp?op=diff&rev=7703&peg=7703
Only the green and red lines are true changes. You can even enable there to "ignore whitespace changes":
http://svn.berlios.de/wsvn/codeblocks/branches/wxpropgrid_debugger/src/plugins/debuggergdb/debuggergdb.cpp?op=diff&rev=7703&peg=7703&ignorews=1
Easy to catch... ;-)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 17, 2012, 08:06:13 pm
http://svn.berlios.de/wsvn/codeblocks?op=comp&compare[]=%2Fbranches%2Fwxpropgrid_debugger%2Fsrc%2Fplugins%2Fdebuggergdb%2Fdebuggergdb.cpp@7688&compare[]=%2Fbranches%2Fwxpropgrid_debugger%2Fsrc%2Fplugins%2Fdebuggergdb%2Fdebuggergdb.cpp@7703

I'm looking at this one and it is pretty broken. I use it because it is the easiest to reach.

My diff tool is set up to show any differences, so I don't commit random changes caused by stripping trailing whitespaces, line ending differences and so on.

p.s. we should add per project/workspace style, because the current global style settings are pretty limiting :(

edit:
seems there is an ignore whitespace button there, too :(
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 17, 2012, 10:42:25 pm
Morten:
Hm, I don't understand your last fix. Can you explain?
Are you sure you've fixed it and not added a workaround for some kind of memory corruption?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 18, 2012, 07:51:08 am
Hm, I don't understand your last fix. Can you explain?
I fully agree that it looks a completely weird but I've seen this in my own applications, too. If you sum a wxString by reference, the and have the reference itself in the equation, too sometimes garbage comes out. I don't know why (maybe I should have look at the affected operators of wxString), but I do know that introducing a temporary (copied) variable works. And in fact the Chinese characters are gone for me.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 18, 2012, 12:21:00 pm
Morten: I wouldn't be surprised if the wx guys have messed the API, once again. But I'll be happy if you take some time and try to find the real cause for the problem.
I did and I found it. This caused a reversal of the initial fix. The problem was in a wrong use of the WinAPI function to retrieve the 8.3 path notation in case the file is not present. (The latter was not handeled correctly). I've fixed this now and forever. However, one thing must be clear: If the file is not present (on Windows) the trial to obtain a 8.3 path (either with or without file) will not succeed. In that case the file name is left as it is, so the argument will be provided "some string" with spaces in it, as you simple cannot convert it to "something without spaces" using Windows file API. This means, the -args argument might indeed get something with spaces and also the path to the debuggee might still contain spaces. This might cause side effects but there is no way to do it properly in the place where I did the modifications.

I also used the wx function now which is cross-platform, so no need for this ugly "GetShortPathNBame" hack for Unixes anymore.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: tomjnx on January 18, 2012, 11:43:23 pm
obFus: are you sure the following does the right thing? It seems to me that only every second command is deleted...

from debuggerdriver.cpp:
void DebuggerDriver::ClearQueue()
{
    int idx = 0;
    // if the first command in the queue is running, delete all others
    // (this will be deleted when done)
    if (m_QueueBusy && !m_DCmds.GetCount())
        idx = 1;
    for (int i = idx; i < (int)m_DCmds.GetCount(); ++i)
    {
        delete m_DCmds;
        m_DCmds.RemoveAt(i);
    }
}
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 19, 2012, 12:21:16 am
No, I'm not sure, but I've fixed it just in case, thank you for the report :)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: tomjnx on January 23, 2012, 12:34:55 am
obFus: In class GdbCmd_AddBreakpoint method ParseOutput, the Backtrace dialog is reloaded. I would have expected to reload the Breakpoints dialog. Am I missing something here?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 23, 2012, 01:36:56 am
Yes, it should be fixed in the branch.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 29, 2012, 02:15:48 pm
I got another feature request:
When you compile C::B against wx 2.9.x and then debug into it using C::B you get tons of debugger warnings like:
warning: In file ../../src/msw/window.cpp at line 581: 'SetFocus' failed with error 0x00000057 (wrong parameter.).
...or:
warning: In file ..\..\include/wx/msw/private.h at line 379: 'GetWindowRect' failed with error 0x00000578 (invalid window handle).

This would be OK, but these are so many, that after roughly 30 seconds GDB and the C::B you are debugging from freezes completely. You have to kill the debugger (gdb) (not the debugee - this does not work) to get the "mother instance" of C::B back. This makes it basically impossible to debug into C::B which is compiled against wx 2.9.x.
Do you see a chance just to ignore a set of warnings, maybe even a pattern? It's done in the compiler plugin: You can skip messages with a certain pattern completely.
Alternatively: Maybe one can set a "debug log level", so that all stuff that starts with "warning" is hidden.

What do you think?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 29, 2012, 02:35:36 pm
Who is printing the warnings? GDB or wxWidgets?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 29, 2012, 02:48:57 pm
Who is printing the warnings? GDB or wxWidgets?
Good question. They appear in the debug log with the prefix "[debug]". So you tell me... ;-)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 29, 2012, 02:53:27 pm
They look like wx ones, probably wx calls OutputDebugString or something like that. Can you try to disable the debugging of wxwidgets?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 29, 2012, 05:21:51 pm
They look like wx ones, probably wx calls OutputDebugString or something like that. Can you try to disable the debugging of wxwidgets?
How do I do that? You mean *not* using --verbose? I am using the release version of the wxWidgets library btw...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 29, 2012, 05:26:25 pm
I'm not really sure, but in 2.9+ they've change the debugging stuff for wx, probably you should check their docs, how to enable/disable debugging.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 29, 2012, 05:27:28 pm
How do I do that? You mean *not* using --verbose? I am using the release version of the wxWidgets library btw...
OK, I tried not using --verbose.
Now I get tons of messages like:
[debug]warning: ../../src/common/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist

That's basically the error I am after. However, the freeze just encounters later and I cannot make this stupid message stop, because it's created permanently on every UpdateUI loop. So this is not a solution. It basically does not allow me to debug C::B using C::B. :-(
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 29, 2012, 05:37:27 pm
Take a look here: http://docs.wxwidgets.org/2.9.3/overview_debugging.html

You can try to set wxDEBUG_LEVEL==0 or provide a null assert handler.

If this doesn't help, you can try to skip the warning line in the GDB_driver::ParseOutput

Put something like this
Code
if (line[i].StartsWith(wxT("warning:"))
{
     m_pDBG->Log(wxT("skipped:")+lines[i]);
}
before the "else if (lines.StartsWith(_T("Error ")) ||" line

I've not tried the code, so it might cause problems.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 29, 2012, 07:39:52 pm
You can try to set wxDEBUG_LEVEL==0 or provide a null assert handler.
Does not help and it shouldn't be an option at compile time anyways.

Code
if (line[i].StartsWith(wxT("warning:"))
{
     m_pDBG->Log(wxT("skipped:")+lines[i]);
}
That would indeed be worth an option, but...

Meanwhile I found out, why this happens:
This GDB command:
set debugevents on
...should definitely be an option on GDB. Turning this feature off made all the messages go away. And that does make sense, because a lot applications "spit out" many of such debugging messages. But during a normal debugging session you don't always want to see them, e.g. when tracing a crash they are usually of no help.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 29, 2012, 07:46:20 pm
This GDB command:
set debugevents on
...should definitely be an option on GDB.

BTW: I am thinking, why not putting all of these GDB initialisation commands:
[debug]> set confirm off
[debug]> set width 0
[debug]> set height 0
[debug]> set breakpoint pending on
[debug]> set print asm-demangle on
[debug]> set unwindonsignal on
[debug]> set print elements 0
[debug]> set debugevents on
[debug]> set disassembly-flavor att
[debug]> catch throw

...in a GDB script which you can edit through the debugger config. Then, you save the script to the application folder and source/use it as you do with "stl-views-1.0.3.gdb", too... What do you think?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 29, 2012, 07:59:15 pm
Some of them are controlled by options in the settings (catch throw, set disassembly-flavor att) and some of the others should not be user edited, because they will break debugging. (width, height, confirm)

"set debugevents on" is used only to detect the pid of the debuggee and when the pid is correctly detected "set debugevents off" should be executed.
I guess the pid reporting has changed, see the beginning of the GDB_driver::ParseOutput functions.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 29, 2012, 08:12:39 pm
"set debugevents on" is used only to detect the pid of the debuggee and when the pid is correctly detected "set debugevents off" should be executed.
I'm afraid it doesn't really work. The messages are less, but still a lot of these warnings make it through... I was wrong because I was pointing at a menu and then the messages are "turned off". That sucks. I guess I'll implement the filter as you suggested finally... Not really "nice" but it should work.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 29, 2012, 08:14:15 pm
So, you're saying that calling "set debugevents off" doesn't remove the messages?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 30, 2012, 06:56:06 am
So, you're saying that calling "set debugevents off" doesn't remove the messages?
Yes, they don't. They only disappear if you work with C::B and the UpdateUI event is not triggered which happens, for example, if you hover over a menu. But what does disappear are other debug messages.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 30, 2012, 09:12:11 am
I guess you're talking about the debugged instance of C::B and UpdateUI, aren't you?
Can you post the full log?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 30, 2012, 11:04:04 am
I guess you're talking about the debugged instance of C::B and UpdateUI, aren't you?
Yes.

Can you post the full log?
Will do, once I get back to the PC where I tried that. So it may take a while... remind me in a few days if I forgot. ;-)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: tomjnx on January 30, 2012, 04:31:01 pm
What is Debug->Add symbol file supposed to do?

It doesn't do anything for me, nor does a grep for idMenuAddSymbolFile return any event handler...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 30, 2012, 04:36:07 pm
It is something left from the past. I'm not sure what it was doing and thats why I've not removed the item.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: tomjnx on January 30, 2012, 04:43:49 pm
How to crash the debugger plugin / C::B:

Open a project, set a breakpoint, start debugging
Edit the breakpoint, add a condition with a symbol that does not exist
Now a message box pops up asking you whether you want to convert the breakpoint into an unconditional one
Kill gdb
Click on either the yes or no button of the popup dialog
Watch the fireworks.

What happens is the following:
Gdb outputs a string saying it doesn't like the condition
OnGDBOutput is called
ParseOutput is called
the cbMessageBox is opened deeply down the call stack of ParseOutput
Now cbMessageBox apparently starts to handle events
gdb terminating causes an event that causes OnGDBTerminated to be called
OnGDBTerminated deallocates the debugger driver (even though code of the debugger driver still runs)

I haven't had an easy + somewhat clean idea on how to fix this... In the end I removed HasDriver, but added LockDriver and UnlockDriver. LockDriver still returns a value indicating whether there is a driver, but if there is, also increments a use counter. Terminate then does not deallocate the driver, but only sets a flag. UnlockDriver then decrements the use counter, and if it reaches zero, checks the terminate flag and does the deallocation if the flag is set. All calls to m_State.GetDriver() need to be surrounded with LockDriver() and UnlockDriver(). Also, there needs to be some buffering to prevent ParseOutput to be reentered...

Is it worth fixing? Dunno. It was definitely unexpected when I hacked the code...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 30, 2012, 06:07:58 pm
Is it worth fixing? Dunno. It was definitely unexpected when I hacked the code...
No, I've switched all my energy to gdb/mi plugin. The current plugin is lost battle. It works, but it will never be stable and fast.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: killerbot on January 30, 2012, 07:20:14 pm
since last weeks changes (debugger plugin // cc plugin) : failing to build :
[even did make clean up to .configure]

Code
make[4]: *** No rule to make target `ccdebuginfo.cpp', needed by `ccdebuginfo.lo'.  
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on January 30, 2012, 07:46:18 pm
since last weeks changes (debugger plugin // cc plugin) : failing to build :
[even did make clean up to .configure]

Code
make[4]: *** No rule to make target `ccdebuginfo.cpp', needed by `ccdebuginfo.lo'.  
I just installed the debugger-branch from my repo, build today (r7736) without pproblems.

Did you run ./bootstrap ?
As far as I know, there are changes in one or more Makefile.am's.
If that's the case the Makefile.in's have to be recreated by (re-)running ./bootstrap .

If that does not work a make distclean before ./bootstrap might help .
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 30, 2012, 08:31:54 pm
killerbot:
I knew, you'll report this problem :)
"make distclean" is needed in this case. I don't know why.

I suggest to start building in a separate directory and before every build to run rm -rf mybuild_folder.
See this post for details how to do it: http://forums.codeblocks.org/index.php/topic,15840.msg106624.html#msg106624
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 30, 2012, 09:01:17 pm
"make distclean" is needed in this case. I don't know why.
May I say something: This autofoo simply sucks. Maybe we should  use cmake on Linux distros...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Jenna on January 30, 2012, 09:30:27 pm
"make distclean" is needed in this case. I don't know why.
May I say something: This autofoo simply sucks. Maybe we should  use cmake on Linux distros...
I think the opposite:
cmake sucks.

Surely a matter of taste.

Please be fair:
in this case it is not an automake, but a user error.

You have moved ccdebuginfo.cpp into another folder, and you have chanegd the appropriate Makefile.am to reflect this change.
But there are artefacts left from former build (all intermediate build-files belong to ccdebuginfo.*, like *.o, *.lo and probably other files), the automake system do not (and can not) know anything about, even if ./bootstrap is run, so they must be either removed manually (or by deleting the whole build-folder, if it is not the source-folder) or by running make distclean.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 30, 2012, 09:37:34 pm
Can you post the full log?
Here it comes:

...with set debugevents off (wx 2.9.x):

Building to ensure sources are up-to-date
Selecting target:
src
Adding source dir: C:\Devel\CodeBlocks\src\
Adding source dir: C:\Devel\CodeBlocks\src\
Adding file: C:\Devel\CodeBlocks\src\devel29\codeblocks.exe
Changing directory to: C:/Devel/CodeBlocks/src/devel29

[debug]PATH=.;C:\Devel\CodeBlocks\src\base\tinyxml;C:\Devel\wxWidgets_293\lib\gcc_dll;C:\Devel\CodeBlocks\src\devel29;C:\Devel\GCC46TDM\bin;C:\Devel\wxWidgets\lib\gcc_dll_system32;C:\Devel\wxWidgets\lib\gcc_dll_system32
[debug]Command-line: C:\Devel\GCC46TDM\bin\gdb.exe -nx -fullname  -quiet  -args C:/Devel/CodeBlocks/src/devel29/codeblocks.exe
[debug]Working dir : C:\Devel\CodeBlocks\src\devel29

Starting debugger: C:\Devel\GCC46TDM\bin\gdb.exe -nx -fullname  -quiet  -args C:/Devel/CodeBlocks/src/devel29/codeblocks.exe
done

[debug]> set prompt >>>>>>cb_gdb:

Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints

[debug]Reading symbols from c:\devel\codeblocks\src\devel29\codeblocks.exe...
[debug]done.
[debug](gdb) >>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (GDB) 7.3
[debug]Copyright (C) 2011 Free Software Foundation, Inc.
[debug]License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[debug]This is free software: you are free to change and redistribute it.
[debug]There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
[debug]and "show warranty" for details.
[debug]This GDB was configured as "mingw32".
[debug]For bug reporting instructions, please see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]>>>>>>cb_gdb:
[debug]> set confirm off

Debugger name and version: GNU gdb (GDB) 7.3

[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 0
[debug]>>>>>>cb_gdb:
[debug]> set debugevents on
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor att
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> source C:\Devel\CodeBlocks\share\codeblocks/scripts/stl-views-1.0.3.gdb
[debug]>>>>>>cb_gdb:
[debug]> set debugevents off
[debug]>>>>>>cb_gdb:
[debug]> directory C:/Devel/CodeBlocks/src/
[debug]>>>>>>cb_gdb:
[debug]> set args --debug-log --no-dde --no-check-associations --multiple-instance --no-splash-screen --verbose --profile=foo
[debug]>>>>>>cb_gdb:
[debug]> run
[debug][New Thread 1832.0x1e00]
[debug][New Thread 1832.0x980]
[debug][New Thread 1832.0x6ac]
[debug][New Thread 1832.0x790]
[debug][New Thread 1832.0x20f8]
[debug][New Thread 1832.0x2340]
[debug][New Thread 1832.0x1cbc]
[debug][New Thread 1832.0x1664]
[debug][New Thread 1832.0x168c]
[debug][New Thread 1832.0x1260]
[debug]warning: ../../src/common/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
--> TONS Of THESE!!!
--> IN BETWEEN SOMESTIMES:
[debug]warning: ../../src/common/menucmn.cpp(976): assert "item" failed
[debug] in Enable(): attempt to enable an item which doesn't exist
[debug]warning: ../../src/common/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
--> AGAIN:TONS Of THESE!!!
[debug]warning: ../../s
[debug]rc/common/wincmn.cpp(468): assert "GetEventHandler() == this" failed in ~wxWindowBase(): any pushed event handlers must have been removed
[debug]warning: ../../src/common/wincmn.cpp(468): assert "GetEventHandler() == this" failed in ~wxWindowBase(): any pushed event handlers must have been removed
[debug]warning: ../../src/common/wincmn.cpp(1448): assert "Assert failure" failed in RemoveEventHandler(): where has the event handler gone?
[debug]Program received signal SIGSEGV, Segmentation fault.
[debug]0x62c04855 in ?? () from c:\devel\codeblocks\src\devel29\wxmsw293u_gcc_custom.dll
[debug]>>>>>>cb_gdb:

Program received signal SIGSEGV, Segmentation fault.
In ?? () (c:\devel\codeblocks\src\devel29\wxmsw293u_gcc_custom.dll)

[debug]> bt 30
[debug]#0  0x62c04855 in ?? () from c:\devel\codeblocks\src\devel29\wxmsw293u_gcc_custom.dll
[debug]#1  0x0a258e57 in CompilerMessages::~CompilerMessages (this=0x9d3c790, __in_chrg=<optimized out>) at C:\Devel\CodeBlocks\src\plugins\compilergcc\compilermessages.cpp:45
[debug]#2  0x01737a2d in LogSlot::~LogSlot (this=0x12a5c7c, __in_chrg=<optimized out>) at C:\Devel\CodeBlocks\src\sdk\logmanager.cpp:35
[debug]#3  0x017381ae in LogManager::~LogManager (this=0x12a5bd0, __in_chrg=<optimized out>) at C:\Devel\CodeBlocks\src\sdk\logmanager.cpp:79
[debug]#4  0x017382b1 in LogManager::~LogManager (this=0x12a5bd0, __in_chrg=<optimized out>) at C:\Devel\CodeBlocks\src\sdk\logmanager.cpp:83
[debug]#5  0x019bf268 in Mgr<LogManager>::Free () at C:/Devel/CodeBlocks/src/include/manager.h:196
[debug]#6  0x017d7d7b in Manager::Shutdown () at C:\Devel\CodeBlocks\src\sdk\manager.cpp:158
[debug]#7  0x00489b1c in MainFrame::OnApplicationClose (this=0x70454a0, event=...) at C:\Devel\CodeBlocks\src\src\main.cpp:3036
[debug]#8  0x62a03c0a in ?? () from c:\devel\codeblocks\src\devel29\wxmsw293u_gcc_custom.dll
[debug]#9  0x00000000 in ?? ()
[debug]>>>>>>cb_gdb:
[debug]> frame 1
[debug]#1  0x0a258e57 in CompilerMessages::~CompilerMessages (this=0x9d3c790, __in_chrg=<optimized out>) at C:\Devel\CodeBlocks\src\plugins\compilergcc\compilermessages.cpp:45
[debug]c:\devel\codeblocks\src\plugins\compilergcc\compilermessages.cpp:45:1167:beg:0xa258e57
[debug]>>>>>>cb_gdb:

#1  0x0a258e57 in CompilerMessages::~CompilerMessages (this=0x9d3c790, __in_chrg=<optimized out>) at C:\Devel\CodeBlocks\src\plugins\compilergcc\compilermessages.cpp:45
c:\devel\codeblocks\src\plugins\compilergcc\compilermessages.cpp:45:1167:beg:0xa258e57
At c:\devel\codeblocks\src\plugins\compilergcc\compilermessages.cpp:45

[debug]> bt 30
[debug]#0  0x62c04855 in ?? () from c:\devel\codeblocks\src\devel29\wxmsw293u_gcc_custom.dll
[debug]#1  0x0a258e57 in CompilerMessages::~CompilerMessages (this=0x9d3c790, __in_chrg=<optimized out>) at C:\Devel\CodeBlocks\src\plugins\compilergcc\compilermessages.cpp:45
[debug]#2  0x01737a2d in LogSlot::~LogSlot (this=0x12a5c7c, __in_chrg=<optimized out>) at C:\Devel\CodeBlocks\src\sdk\logmanager.cpp:35
[debug]#3  0x017381ae in LogManager::~LogManager (this=0x12a5bd0, __in_chrg=<optimized out>) at C:\Devel\CodeBlocks\src\sdk\logmanager.cpp:79
[debug]#4  0x017382b1 in LogManager::~LogManager (this=0x12a5bd0, __in_chrg=<optimized out>) at C:\Devel\CodeBlocks\src\sdk\logmanager.cpp:83
[debug]#5  0x019bf268 in Mgr<LogManager>::Free () at C:/Devel/CodeBlocks/src/include/manager.h:196
[debug]#6  0x017d7d7b in Manager::Shutdown () at C:\Devel\CodeBlocks\src\sdk\manager.cpp:158
[debug]#7  0x00489b1c in MainFrame::OnApplicationClose (this=0x70454a0, event=...) at C:\Devel\CodeBlocks\src\src\main.cpp:3036
[debug]#8  0x62a03c0a in ?? () from c:\devel\codeblocks\src\devel29\wxmsw293u_gcc_custom.dll
[debug]#9  0x00000000 in ?? ()
[debug]>>>>>>cb_gdb:
[debug]> frame 1
[debug]#1  0x0a258e57 in CompilerMessages::~CompilerMessages (this=0x9d3c790, __in_chrg=<optimized out>) at C:\Devel\CodeBlocks\src\plugins\compilergcc\compilermessages.cpp:45
[debug]c:\devel\codeblocks\src\plugins\compilergcc\compilermessages.cpp:45:1167:beg:0xa258e57
[debug]>>>>>>cb_gdb:

#1  0x0a258e57 in CompilerMessages::~CompilerMessages (this=0x9d3c790, __in_chrg=<optimized out>) at C:\Devel\CodeBlocks\src\plugins\compilergcc\compilermessages.cpp:45
c:\devel\codeblocks\src\plugins\compilergcc\compilermessages.cpp:45:1167:beg:0xa258e57


...with set debugevents on (wx 2.9.x):

Building to ensure sources are up-to-date
Selecting target:
src
Adding source dir: C:\Devel\CodeBlocks\src\
Adding source dir: C:\Devel\CodeBlocks\src\
Adding file: C:\Devel\CodeBlocks\src\devel29\codeblocks.exe
Changing directory to: C:/Devel/CodeBlocks/src/devel29

[debug]PATH=.;C:\Devel\CodeBlocks\src\base\tinyxml;C:\Devel\wxWidgets_293\lib\gcc_dll;C:\Devel\CodeBlocks\src\devel29;C:\Devel\GCC46TDM\bin;C:\Devel\wxWidgets\lib\gcc_dll_system32;C:\Devel\wxWidgets\lib\gcc_dll_system32
[debug]Command-line: C:\Devel\GCC46TDM\bin\gdb.exe -nx -fullname  -quiet  -args C:/Devel/CodeBlocks/src/devel29/codeblocks.exe
[debug]Working dir : C:\Devel\CodeBlocks\src\devel29

Starting debugger: C:\Devel\GCC46TDM\bin\gdb.exe -nx -fullname  -quiet  -args C:/Devel/CodeBlocks/src/devel29/codeblocks.exe
done

[debug]> set prompt >>>>>>cb_gdb:

Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints

[debug]Reading symbols from c:\devel\codeblocks\src\devel29\codeblocks.exe...
[debug]done.
[debug](gdb) >>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (GDB) 7.3
[debug]Copyright (C) 2011 Free Software Foundation, Inc.
[debug]License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[debug]This is free software: you are free to change and redistribute it.
[debug]There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
[debug]and "show warranty" for details.
[debug]This GDB was configured as "mingw32".
[debug]For bug reporting instructions, please see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]>>>>>>cb_gdb:
[debug]> set confirm off

Debugger name and version: GNU gdb (GDB) 7.3

[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 0
[debug]>>>>>>cb_gdb:
[debug]> set debugevents on
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor att
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> source C:\Devel\CodeBlocks\share\codeblocks/scripts/stl-views-1.0.3.gdb
[debug]>>>>>>cb_gdb:
[debug]> directory C:/Devel/CodeBlocks/src/
[debug]>>>>>>cb_gdb:
[debug]> set args --debug-log --no-dde --no-check-associations --multiple-instance --no-splash-screen --verbose --profile=foo
[debug]>>>>>>cb_gdb:
[debug]> run
[debug]gdb: windows_init_thread_list

Child process PID: 7920

[debug][New Thread 7920.0x56c]
[debug][New Thread 7920.0x20cc]
[debug][New Thread 7920.0xa7c]
[debug][New Thread 7920.0xad8]
[debug][New Thread 7920.0x11c]
[debug][New Thread 7920.0xee4]
[debug][New Thread 7920.0x97c]
[debug][New Thread 7920.0xc44]
[debug][New Thread 7920.0x2324]
[debug][New Thread 7920.0x1080]
[debug]warning: ../../src/common/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
--> TONS Of THESE!!!
[debug]warning: ../../src/common/wincmn.cpp(468): assert "GetEventHandler() == this" failed in ~wxWindowBase(): any pushed event handlers must have been removed
[debug]warning: ../../src/common/wincmn.cpp(468): assert "GetEventHandler() == this" failed in ~wxWindowBase(): any pushed event handlers must have been removed
[debug]warning: ../../src/common/wincmn.cpp(1448): assert "Assert failure" failed in RemoveEventHandler(): where has the event handler gone?
[debug]Program received signal SIGSEGV, Segmentation fault.
[debug]0x49444f43 in ?? ()
[debug]>>>>>>cb_gdb:

Program received signal SIGSEGV, Segmentation fault.
In ?? () ()

[debug]> set debugevents off
[debug]>>>>>>cb_gdb:
[debug]> bt 30
[debug]#0  0x49444f43 in ?? ()
[debug]#1  0x62c04858 in ?? () from c:\devel\codeblocks\src\devel29\wxmsw293u_gcc_custom.dll
[debug]#2  0x0a258e57 in CompilerMessages::~CompilerMessages (this=0x9d4b000, __in_chrg=<optimized out>) at C:\Devel\CodeBlocks\src\plugins\compilergcc\compilermessages.cpp:45
[debug]#3  0x01437a2d in LogSlot::~LogSlot (this=0x68b5c7c, __in_chrg=<optimized out>) at C:\Devel\CodeBlocks\src\sdk\logmanager.cpp:35
[debug]#4  0x014381ae in LogManager::~LogManager (this=0x68b5bd0, __in_chrg=<optimized out>) at C:\Devel\CodeBlocks\src\sdk\logmanager.cpp:79
[debug]#5  0x014382b1 in LogManager::~LogManager (this=0x68b5bd0, __in_chrg=<optimized out>) at C:\Devel\CodeBlocks\src\sdk\logmanager.cpp:83
[debug]#6  0x016bf268 in Mgr<LogManager>::Free () at C:/Devel/CodeBlocks/src/include/manager.h:196
[debug]#7  0x014d7d7b in Manager::Shutdown () at C:\Devel\CodeBlocks\src\sdk\manager.cpp:158
[debug]#8  0x00489b1c in MainFrame::OnApplicationClose (this=0x6ef54a0, event=...) at C:\Devel\CodeBlocks\src\src\main.cpp:3036
[debug]#9  0x62a03c0a in ?? () from c:\devel\codeblocks\src\devel29\wxmsw293u_gcc_custom.dll
[debug]#10 0x00000000 in ?? ()
[debug]>>>>>>cb_gdb:
[debug]> frame 2
[debug]#2  0x0a258e57 in CompilerMessages::~CompilerMessages (this=0x9d4b000, __in_chrg=<optimized out>) at C:\Devel\CodeBlocks\src\plugins\compilergcc\compilermessages.cpp:45
[debug]c:\devel\codeblocks\src\plugins\compilergcc\compilermessages.cpp:45:1167:beg:0xa258e57
[debug]>>>>>>cb_gdb:

#2  0x0a258e57 in CompilerMessages::~CompilerMessages (this=0x9d4b000, __in_chrg=<optimized out>) at C:\Devel\CodeBlocks\src\plugins\compilergcc\compilermessages.cpp:45
c:\devel\codeblocks\src\plugins\compilergcc\compilermessages.cpp:45:1167:beg:0xa258e57
At c:\devel\codeblocks\src\plugins\compilergcc\compilermessages.cpp:45

[debug]> bt 30
[debug]#0  0x49444f43 in ?? ()
[debug]#1  0x62c04858 in ?? () from c:\devel\codeblocks\src\devel29\wxmsw293u_gcc_custom.dll
[debug]#2  0x0a258e57 in CompilerMessages::~CompilerMessages (this=0x9d4b000, __in_chrg=<optimized out>) at C:\Devel\CodeBlocks\src\plugins\compilergcc\compilermessages.cpp:45
[debug]#3  0x01437a2d in LogSlot::~LogSlot (this=0x68b5c7c, __in_chrg=<optimized out>) at C:\Devel\CodeBlocks\src\sdk\logmanager.cpp:35
[debug]#4  0x014381ae in LogManager::~LogManager (this=0x68b5bd0, __in_chrg=<optimized out>) at C:\Devel\CodeBlocks\src\sdk\logmanager.cpp:79
[debug]#5  0x014382b1 in LogManager::~LogManager (this=0x68b5bd0, __in_chrg=<optimized out>) at C:\Devel\CodeBlocks\src\sdk\logmanager.cpp:83
[debug]#6  0x016bf268 in Mgr<LogManager>::Free () at C:/Devel/CodeBlocks/src/include/manager.h:196
[debug]#7  0x014d7d7b in Manager::Shutdown () at C:\Devel\CodeBlocks\src\sdk\manager.cpp:158
[debug]#8  0x00489b1c in MainFrame::OnApplicationClose (this=0x6ef54a0, event=...) at C:\Devel\CodeBlocks\src\src\main.cpp:3036
[debug]#9  0x62a03c0a in ?? () from c:\devel\codeblocks\src\devel29\wxmsw293u_gcc_custom.dll
[debug]#10 0x00000000 in ?? ()
[debug]>>>>>>cb_gdb:
[debug]> frame 2
[debug]#2  0x0a258e57 in CompilerMessages::~CompilerMessages (this=0x9d4b000, __in_chrg=<optimized out>) at C:\Devel\CodeBlocks\src\plugins\compilergcc\compilermessages.cpp:45
[debug]c:\devel\codeblocks\src\plugins\compilergcc\compilermessages.cpp:45:1167:beg:0xa258e57
[debug]>>>>>>cb_gdb:

#2  0x0a258e57 in CompilerMessages::~CompilerMessages (this=0x9d4b000, __in_chrg=<optimized out>) at C:\Devel\CodeBlocks\src\plugins\compilergcc\compilermessages.cpp:45
c:\devel\codeblocks\src\plugins\compilergcc\compilermessages.cpp:45:1167:beg:0xa258e57


...is that of any help? BTW: The crash is "normal" if you quit C::B compiled against wx2.9.x. Somwhere the event queue is screwed (we have more PushEventHandler calls than RemoveEventHandler and this is serioulsy wrong). I remember we (actually Yiannis) did ugly hacking with the plugin load/unload mechanism to make it work. This might be the reason.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 30, 2012, 09:40:56 pm
May I say something: This autofoo simply sucks. Maybe we should  use cmake on Linux distros...
I think the opposite:
cmake sucks.
[/quote]
Ok - you might be right - I remember hacking cmake to make it work with wxWidgets earlier and this was no fun.

So: Make we should then get rid of automake completely and force people using a compiled C::B  from a package manager to compile C::B... hehe.. :D
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: tomjnx on January 30, 2012, 10:24:59 pm
So: Make we should then get rid of automake completely and force people using a compiled C::B  from a package manager to compile C::B... hehe.. :D

If you tell me how to compile using C::B without X11 on Linux... Distribution buildservers usually have no X11 8-)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: tomjnx on January 30, 2012, 10:25:57 pm
No, I've switched all my energy to gdb/mi plugin. The current plugin is lost battle. It works, but it will never be stable and fast.

Where is the gdb/mi plugin, then?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 30, 2012, 10:33:19 pm
tomjnx: here: svn://smrt.is-a-geek.org/cb_gdb_mi/debbugger_gdbmi

Morten: autotools is the only sensible way to distribute open source software.

About the warning:
Looking at your logs, I can conclude that filtering the warnings is the only way forward. Even if "set debugevents off" was working. If would have been executed at the first breakpoint hit, which may be too late and it could cause the log to be filled with garbage.

Fill free to test the filtering and then post a patch, so I can test it, too.

Edit: I've talked to the gdb people and they suggested filing a bug report in the gdb's bugzilla. Can you do it?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 31, 2012, 12:21:57 am
Morten: autotools is the only sensible way to distribute open source software.
If you tell me how to compile using C::B without X11 on Linux... Distribution buildservers usually have no X11 8-)
Guys, didn't you see the smiley? I know this is not an option. However, it's hard to believe that automake is still an elegant way in the 21st century. But I also don't know a better solution as I am not into Unix/Linux that much.

Edit: I've talked to the gdb people and they suggested filing a bug report in the gdb's bugzilla. Can you do it?
Done, see/subscribe here:
http://sourceware.org/bugzilla/show_bug.cgi?id=13635
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 31, 2012, 12:32:47 am
Fill free to test the filtering and then post a patch, so I can test it, too.
I looked into it (GDB_driver::ParseOutput) a little and I see this:
   if (!want_debug_events &&
        (output.StartsWith(_T("gdb: ")) ||
        output.StartsWith(_T("Warning: ")) ||
        output.StartsWith(_T("ContinueDebugEvent "))))
    {
        return;
    }

Notice the capital "W" in "Warning: ". Maybe it is as easy as adding another "|| output.StartsWith(_T("warning: "))"... ;-)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 31, 2012, 12:35:04 am
Yes, do it test and report if it is working:)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 31, 2012, 12:39:01 am
Yes, do it test and report if it is working:)
I'll try, but what's needed in addition is to switch off the debug events after the PID detection. as you described here:
"set debugevents on" is used only to detect the pid of the debuggee and when the pid is correctly detected "set debugevents off" should be executed.
I guess the pid reporting has changed, see the beginning of the GDB_driver::ParseOutput functions.
How/when/where would I do that best?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 31, 2012, 12:45:45 am
Check why the current test doesn't work. Probably the output of gdb has changed.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 31, 2012, 09:07:45 pm
... I had the weird idea to run C::B with only the debugger plugin and see how well C::B would work as debugger front end.

So far, "nothing" without a project works, and loading a project without an active compiler plugin is rejected. (:-\) But what also does not work is attaching to a process. Then I see this message:
---------------------------
Error
---------------------------
This project is configured to use an invalid debugger.
The operation failed...
---------------------------
OK   
---------------------------
However, that is not correct, because there is no need for a project and the debugger is setup correctly. Maybe you see a chance to make this work... ;-)
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on January 31, 2012, 09:16:44 pm
Check why the current test doesn't work. Probably the output of gdb has changed.
So, I added the lower letter "warning" and I am not really a step further. The log now looks like this:
[debug]>>>>>>cb_gdb:
[debug]> set confirm off

Debugger name and version: GNU gdb (GDB) 7.3

[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 0
[debug]>>>>>>cb_gdb:
[debug]> set debugevents on
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor att
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> source C:\Devel\CodeBlocks\share\codeblocks/scripts/stl-views-1.0.3.gdb
[debug]>>>>>>cb_gdb:
[debug]> directory C:/Devel/CodeBlocks/src/
[debug]>>>>>>cb_gdb:
[debug]> set args --debug-log --no-dde --no-check-associations --multiple-instance --no-splash-screen --verbose --profile=foo
[debug]>>>>>>cb_gdb:
[debug]> run
[debug]gdb: windows_init_thread_list

Child process PID: 8412

[debug][New Thread 8412.0xd0c]
[debug]2.dll" at 0x72560000.
[debug][New Thread 8412.0x21bc]
[debug][New Thread 8412.0x2330]
[debug][New Thread 8412.0x2018]
[debug][New Thread 8412.0x224c]
[debug][New Thread 8412.0x23a0]
[debug][New Thread 8412.0xdd4]
[debug][New Thread 8412.0x758]
[debug][New Thread 8412.0x1c34]
[debug][New Thread 8412.0x217c]
[debug][New Thread 8412.0x2248]
[debug] in Enable(): attempt to enable an item which doesn't exist
[debug]wa
[debug]rning: ../../src/common/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug]n Enable(): attempt to enable an item which doesn't exist
[debug]warn
[debug]ing: ../../src/common/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug]Enable(): attempt to enable an item which doesn't exist
[debug]warnin
[debug]g: ../../src/common/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug]able(): attempt to enable an item which doesn't exist
[debug]warning:
[debug] ../../src/common/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug]le(): attempt to enable an item which doesn't exist
[debug]./../src/common/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug](): attempt to enable an item which doesn't exist
[debug]../src/common/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug]: attempt to enable an item which doesn't exist
[debug]/src/common/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug]attempt to enable an item which doesn't exist
[debug]rc/common/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug][New Thread 8412.0x82c]
[debug]tempt to enable an item which doesn't exist
[debug]/common/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug]mpt to enable an item which doesn't exist
[debug]ommon/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug]t to enable an item which doesn't exist
[debug]mon/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug]to enable an item which doesn't exist
[debug]n/menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug] enable an item which doesn't exist
[debug]menucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug]nable an item which doesn't exist
[debug]nucmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug]ble an item which doesn't exist
[debug]cmn.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug]e an item which doesn't exist
[debug]n.cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug]an item which doesn't exist
[debug]cpp(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist
[debug] item which doesn't exist
[debug]p(976): assert "item" failed in Enable(): attempt to enable an item which doesn't exist

...so you see that due to the fact that some messages are strangely interrupted (WHY btw - I think this is a bug!!!) it does not really help. I get less messages, but still too much and still the debugger freezes after some time. Maybe a low-level filtering as suggested will help...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on January 31, 2012, 09:38:36 pm
Seems that a non buffered API is used to print the warnings... You'll have to hack wxwidgets to stop them.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on February 01, 2012, 06:56:34 am
...so you see that due to the fact that some messages are strangely interrupted (WHY btw - I think this is a bug!!!) it does not really help. I get less messages, but still too much and still the debugger freezes after some time. Maybe a low-level filtering as suggested will help...
Does this code
Code
    static wxString buffer;
    buffer << output << _T('\n');

    m_pDBG->DebugLog(output);
In the function void GDB_driver::ParseOutput(const wxString& output) cause this issue?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on February 01, 2012, 09:19:00 am
No, I've switched all my energy to gdb/mi plugin. The current plugin is lost battle. It works, but it will never be stable and fast.
BTW: I am not sure how far you are with the plugin, bus I have found a few interesting projects that provide a parser for the GDB/MI interface, like these:
.,..maybe it is of help. But it seems to me that the MI is under development, and you need to take care about what version of GDB you are targeting...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 01, 2012, 09:27:31 am
I've looked at libmigdb, but I decided to write my parser.
I have a working parser and stepping/breakpoints/watches should work.

The good thing about gdb/mi is that the communication protocol is stable. So you always parse the messages, but you might get new fields.
And this is not as problematic as the gdb/cli output, which changes more often.
Also compiling latest gdb is not that of a problem, as it turned out.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on February 25, 2012, 03:42:51 pm
Ok - here comes another issue... ;-)

- consider this code:
Code
#include <iostream>

void funca()
{
    std::cout << "Hello!" << std::endl;
}

int main()
{
    funca();
    return 0;
}
- place a BP at the line "funca();"
- continue to step through it with Next (F7)
- after a few times, everything comes to a halt.

You cannot stop/pause/continue/whats-over the debugger or C::B. You have to kill the debugger (not the debugee - that's impossible!) using the task manager.

Here is the debuggers debug log:
[debug](gdb) >>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (GDB) 7.3
[debug]Copyright (C) 2011 Free Software Foundation, Inc.
[debug]License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[debug]This is free software: you are free to change and redistribute it.
[debug]There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
[debug]and "show warranty" for details.
[debug]This GDB was configured as "mingw32".
[debug]For bug reporting instructions, please see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]>>>>>>cb_gdb:
[debug]> set confirm off

Debugger name and version: GNU gdb (GDB) 7.3

[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 0
[debug]>>>>>>cb_gdb:
[debug]> set debugevents on
[debug]>>>>>>cb_gdb:
[debug]> set new-console on
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor att
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> source C:\Devel\CodeBlocks\src\devel29\share\codeblocks/scripts/stl-views-1.0.3.gdb
[debug]>>>>>>cb_gdb:
[debug]> directory C:/Users/morten/Desktop/MyCon/
[debug]>>>>>>cb_gdb:
[debug]> break "C:/Users/morten/Desktop/MyCon/main.cpp:10"
[debug]Breakpoint 2 at 0x401347: file C:\Users\morten\Desktop\MyCon\main.cpp, line 10.
[debug]>>>>>>cb_gdb:
[debug]> run
[debug]gdb: windows_init_thread_list

Child process PID: 7980

[debug][New Thread 7980.0x18c]
[debug]Breakpoint 2, main () at C:\Users\morten\Desktop\MyCon\main.cpp:10
[debug]c:\users\morten\desktop\mycon\main.cpp:10:101:beg:0x401347
[debug]>>>>>>cb_gdb:

At c:\users\morten\desktop\mycon\main.cpp:10

[debug]> set debugevents off
[debug]>>>>>>cb_gdb:
[debug]> next
[debug]c:\users\morten\desktop\mycon\main.cpp:11:115:beg:0x40134c
[debug]>>>>>>cb_gdb:

At c:\users\morten\desktop\mycon\main.cpp:11

[debug]> next
[debug]c:\users\morten\desktop\mycon\main.cpp:12:130:beg:0x401351
[debug]>>>>>>cb_gdb:

At c:\users\morten\desktop\mycon\main.cpp:12

[debug]> next
[debug]250   ../mingw/crt1.c: No such file or directory.
[debug]__mingw_CRTStartup () at ../mingw/crt1.c:250
[debug]   in ../mingw/crt1.c
[debug]>>>>>>cb_gdb:
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on February 25, 2012, 03:50:10 pm
Ok - here comes another issue... ;-)
...and another one:
From time to time I see this in the debuggers log when stepping through code using F7:
[debug]> next
[debug]Cannot find bounds of current function
[debug]>>>>>>cb_gdb:

After that, the debugger plugin is frozen and nothing happens until I kill the debugger (not the debugee - that's impossible!).
I didn't find a way to reproduce, not a minimal sample, but according to this:
http://bytes.com/topic/c/answers/786078-error-cannot-find-function-bounds
...the reason is a "buffer overrun problem somewhere in an inner function".
Nasty - but this should be handled correctly.

BTW: The sample to reproduce shown there does not reproduce this problem. :-(
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 25, 2012, 03:53:20 pm
You're reporting this for the second time.

About the first one, can you state your exact version of the compiler and does it happen when running on windows 7 x64 bit?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: ollydbg on February 25, 2012, 03:56:35 pm
Ok - here comes another issue... ;-)

- consider this code:
Code
#include <iostream>

void funca()
{
    std::cout << "Hello!" << std::endl;
}

int main()
{
    funca();
    return 0;
}
- place a BP at the line "funca();"
- continue to step through it with Next (F7)
- after a few times, everything comes to a halt.

It works fine here xunxun's gcc 4.6.3 and gdb cvs build my self.
Code
[debug]>>>>>>cb_gdb:
[debug]> break "E:/code/cb/test_code/mortenr2012-01-15/main.cpp:10"
[debug]Breakpoint 2 at 0x401697: file E:\code\cb\test_code\mortenr2012-01-15\main.cpp, line 10.
[debug]>>>>>>cb_gdb:
[debug]> run
[debug]Starting program: E:\code\cb\test_code\mortenr2012-01-15\bin\Debug\mortenr2012-01-15.exe
[debug]gdb: windows_init_thread_list

Child process PID: 5332

[debug][New Thread 5332.0x1178]
[debug]Breakpoint 2, main () at E:\code\cb\test_code\mortenr2012-01-15\main.cpp:10
[debug]E:\code\cb\test_code\mortenr2012-01-15\main.cpp:10:101:beg:0x401697
[debug]>>>>>>cb_gdb:

At E:\code\cb\test_code\mortenr2012-01-15\main.cpp:10

[debug]> set debugevents off
[debug]>>>>>>cb_gdb:
[debug]> next
[debug]E:\code\cb\test_code\mortenr2012-01-15\main.cpp:11:115:beg:0x40169c
[debug]>>>>>>cb_gdb:

At E:\code\cb\test_code\mortenr2012-01-15\main.cpp:11

[debug]> next
[debug]E:\code\cb\test_code\mortenr2012-01-15\main.cpp:12:130:beg:0x4016a1
[debug]>>>>>>cb_gdb:

At E:\code\cb\test_code\mortenr2012-01-15\main.cpp:12

[debug]> next
[debug]0x0040146d in __tmainCRTStartup ()
[debug]>>>>>>cb_gdb:

In __tmainCRTStartup () ()

[debug]> bt 30
[debug]#0  0x0040146d in __tmainCRTStartup ()
[debug]#1  0x7c817077 in RegisterWaitForInputIdle () from C:\WINDOWS\system32\kernel32.dll
[debug]#2  0x00000000 in ?? ()
[debug]>>>>>>cb_gdb:
[debug]> next
[debug]Single stepping until exit from function __tmainCRTStartup,
[debug]which has no line number information.
[debug][Inferior 1 (process 5332) exited normally]
[debug]>>>>>>cb_gdb:

[Inferior 1 (process 5332) exited normally]

[debug]> quit

Debugger finished with status 0
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 25, 2012, 04:15:16 pm
ollydbg: That's why I've asked for the exact compiler version. This happens when the libc is build with debug symbols or at least happens on my centos/ubuntu.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on February 25, 2012, 05:26:09 pm
You're reporting this for the second time.
:o Really? In fact, I can't remember. :-[ - Which one of the two reports do you mean?

Anyways...
About the first one, can you state your exact version of the compiler and does it happen when running on windows 7 x64 bit?
The compiler if GCC-TDM 4.6.1 (32 bit) and I am on Windows 7, 64 bit, but using a 32 bit compiled version of C::B.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on February 25, 2012, 05:30:47 pm
Something completely different: Do you think I should switch to the GDB/MI plugin? I know you have less interest in fixing the current plugin - I just wonder if the GDB/MI one is already usable?!

BTW: SVN access to this plugin is not possible for me anymore ("Unknown host: smrt.is-a-geek.org"). Did you move it?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on February 25, 2012, 05:46:41 pm
BTW: SVN access to this plugin is not possible for me anymore ("Unknown host: smrt.is-a-geek.org"). Did you move it?
I've lost the domain name and now I use different one cmpt.benbmp.org.
I doubt it is usable in production, thought. I've tried to build it on centos, but failed, so I don't use it actively at the moment.
And unfortunately I can't find enough time and concentration to work on it.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: cbexaminr on March 02, 2012, 09:20:46 pm
... I had the weird idea to run C::B with only the debugger plugin and see how well C::B would work as debugger front end.

Morten - FWIW - I was _not_ running debugger plugin only (AsFarAsIKnow), but I think I did have such functionality working in the stuff presented back around and/or prior to this post:
http://forums.codeblocks.org/index.php/topic,10908.msg98311.html#msg98311

as I wanted/needed such functionality (and would _still_ like to have it within C::B).  My efforts at that time were not, however, accepted and applied. 

If you're interested in such functionality, you might look at the patches I submitted then against their related source control versions, and find whatever changes I made at that time.

So far, "nothing" without a project works, and loading a project without an active compiler plugin is rejected. (:-\) But what also does not work is attaching to a process. Then I see this message:
---------------------------
Error
---------------------------
This project is configured to use an invalid debugger.
The operation failed...
---------------------------
OK   
---------------------------
However, that is not correct, because there is no need for a project and the debugger is setup correctly. Maybe you see a chance to make this work... ;-)

Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on March 03, 2012, 01:04:50 pm
... I had the weird idea to run C::B with only the debugger plugin and see how well C::B would work as debugger front end.
http://forums.codeblocks.org/index.php/topic,10908.msg98311.html#msg98311
Well this patch embeds not only one, but many changes. Is it possible, that for each change you create an own patch (that's how it always should be).
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on March 03, 2012, 03:20:06 pm
Well this patch embeds not only one, but many changes. Is it possible, that for each change you create an own patch (that's how it always should be).
Sorry, to say this, but my trials to apply the patch on trunk of the debugger's branch failed miserably. I guess w/o an update (you might have continued to use it in your local copy) it will be hard to see if that's what I had in mind...
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on March 03, 2012, 07:43:37 pm
The patch won't apply, because the GetCommandLine has been change. But if you read, my comments about the patch, you'll see that I'm pretty much against it.
This a plugin specific feature, which should not be required by all other plugins implementing a debugger.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on March 03, 2012, 08:20:03 pm
About attaching:
As far as I can see attaching to a running program works even if there is no loaded project.
The only requirement is that you should not use the "Use active target's debugger" option in the "Debug->Active debuggers".
If you have a non working case for attaching, please report the details.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Pecan on April 03, 2012, 04:02:05 pm
SVN 7916 (shows in debugger as 7904)
svn build  rev 7904 (2012-03-19 21:48:48)   gcc 4.3.1 Windows/unicode - 32 bit

When aborting a Hello World compile and run, CB gets hung up. The compiler buttons are disabled and the system "says" the compiler is in use.

The only way out (I've found) is just to kill CB.
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on April 03, 2012, 04:26:11 pm
Please post the exact steps to reproduce this.
Does it happen every time or it is a random thing?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Pecan on April 04, 2012, 12:02:45 pm
Please post the exact steps to reproduce this.
Does it happen every time or it is a random thing?

1) Using the wizard, create a default console hello world project
2) build the project
3) run the project
4) use the little red [ x ] to kill the running console window.
5) CB is hung. Always happens

svn build  rev 7904 (2012-03-19 21:48:48)   gcc 4.3.1 Windows/unicode - 32 bit
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on April 04, 2012, 12:13:37 pm
Does this happen with the trunk's version?
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: Pecan on April 05, 2012, 10:47:22 pm
Does this happen with the trunk's version?

Yes, pushing the abort button stops the pgm, but all build menus and toolbar buttons are grayed out.

So, I guess, it's a trunk problem.

Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: MortenMacFly on April 12, 2012, 09:13:26 am
...another one:
After the merge attaching to a process makes GDB crash. This used to work in the branch...?! Here is the debug log:

[debug]Command-line: C:\Devel\GCC46TDM\bin\gdb.exe -nx -fullname  -quiet
[debug]Working dir : D:\Code\Dummy

Starting debugger: C:\Devel\GCC46TDM\bin\gdb.exe -nx -fullname  -quiet
done

[debug]> set prompt >>>>>>cb_gdb:

Registered new type: wxString
Registered new type: STL String
Registered new type: STL Vector
Setting breakpoints
Attaching to program with pid: 2928

[debug](gdb) >>>>>>cb_gdb:
[debug]> show version
[debug]GNU gdb (GDB) 7.3
[debug]Copyright (C) 2011 Free Software Foundation, Inc.
[debug]License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
[debug]This is free software: you are free to change and redistribute it.
[debug]There is NO WARRANTY, to the extent permitted by law.  Type "show copying"
[debug]and "show warranty" for details.
[debug]This GDB was configured as "mingw32".
[debug]For bug reporting instructions, please see:
[debug]<http://www.gnu.org/software/gdb/bugs/>.
[debug]>>>>>>cb_gdb:
[debug]> set confirm off

Debugger name and version: GNU gdb (GDB) 7.3

[debug]>>>>>>cb_gdb:
[debug]> set width 0
[debug]>>>>>>cb_gdb:
[debug]> set height 0
[debug]>>>>>>cb_gdb:
[debug]> set breakpoint pending on
[debug]>>>>>>cb_gdb:
[debug]> set print asm-demangle on
[debug]>>>>>>cb_gdb:
[debug]> set unwindonsignal on
[debug]>>>>>>cb_gdb:
[debug]> set print elements 0
[debug]>>>>>>cb_gdb:
[debug]> set debugevents on
[debug]>>>>>>cb_gdb:
[debug]> set disassembly-flavor att
[debug]>>>>>>cb_gdb:
[debug]> catch throw
[debug]No symbol table is loaded.  Use the "file" command.
[debug]Catchpoint 1 (throw)
[debug]>>>>>>cb_gdb:
[debug]> source C:\Devel\CodeBlocks\share\codeblocks/scripts/stl-views-1.0.3.gdb
[debug]>>>>>>cb_gdb:
[debug]> attach 2928
[debug]gdb: windows_init_thread_list

Child process PID: 2928

[debug][New Thread 2928.0xb74]
[debug][New Thread 2928.0xd98]
[debug][New Thread 2928.0xe2c]
[debug][New Thread 2928.0x35c]
[debug][New Thread 2928.0x104c]
[debug]=b74 code=LOAD_DLL_DEBUG_EVENT)

-> CRASH.

I'll try on the command lien to see what happens there... However, can somebody try to attach to a process, too?

EDIT: Crashes on the command line, too... WTF?!
Title: Re: Splitting debugger in two - specific debugger and common GUI
Post by: oBFusCATed on April 12, 2012, 09:21:34 am
Your gdb is broken?

BTW: I'm locking this topic, because we've merged the code in trunk. If you have any questions/problems/suggestions/patches start a new topic in the appropriate sub-forum.