Splitting debugger in two - specific debugger and common GUI

[cbexaminr]

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.

[cbexaminr]

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

[dmoore]

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?

[dmoore]

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)

[oBFusCATed]

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.

[cbexaminr]

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

[oBFusCATed]

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

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

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?

[cbexaminr]

[content removed, see two posts above (Jens)]

[dmoore]

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?)

[oBFusCATed]

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.

[dmoore]

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

[cbexaminr]

What about integrating your cooker in C::B? 

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?

[oBFusCATed]

Soon    :lol:

[oBFusCATed]

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

[cbexaminr]

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.