default debugger executables

[René J.V. Bertin]

On Wednesday September 14 2016 21:25:31 Aetf wrote:

> For the debugger executable config entry, if it's empty, the plugin will
> use whatever comes first in PATH. (`gdb` for gdb plugin and `lldb-mi` for
> lldb plugin). On my linux box (Archlinux), while lldb has version numbered
> executables, there are also unversioned symlinks to latest version. Another
> difference between OSX and linux llvm?

Actually, no. I get my Debuntu LLVM packages directly from llvm.org (or Debian, depending on which has the latest version), and they don't have those symlinks.

> The unsolved problem is, who is responsible for initializing the global
> launch configuration in the first place, and adding menu actions to
> KDevelop. Neither gdb nor lldb plugin is a good choice for this. And it is
> too C/C++ specific to be added to kdevplatform.

I suppose that at least part of the shared functionality could go into the host app (KDevelop) instead of having to be duplicated in each debugger plugin.
Or it can be a shared library with an initialisation step that does its actual work only once.

There's another unsolved problem IMHO that has much wider implications. There is too little distinction between settings that apply across sessions, and those that apply per session, at least from the user's point of view. From the program's point of view it's somewhat the opposite: there are global and per-session options, and as far as I know there is no possibility to have a global setting that's overridden by a session setting.

[quoth Aleix]
> For now, I'd say it's okay to have a special action such as "Attach
> gdb to process..." and "Attach lldb to process..".

Or via a submenu (Run/Attach to Process/...). The debugger/common code (library?) could set up the parent menu actions, deactivated as long as no debugger plugins register the feature, and debugger plugins could register themselves (and subsequently appear in the sub menu) if they provide the attach or examine core feature. Shouldn't be too complicated to implement, and it gives a nice direct interface that's just a bit more subtle than multiple menu actions all "with debugger XYZ" in their title.

> Being 2 disjoint projects, it's unlikely that both of them offer
> exactly the same things.

Hard to say, actually, because in the end it will depend on how well the IDE plugin exposes the particular strengths of each debugger. The lldb debugger leverages the lldb-mi driver which masquerades as gdb (in MI mode) and you control it through an interface that's clearly shared (there are not 2 debugger toolbars as far as I can tell, for instance). That suggests the feature sets will be largely identical.
I did get the impression though that the lldb plugin does at least as good a job at displaying the values of key Qt object types as the gdb plugin does.

Cheers,
R.