Gdb Remote launch targets for CoreBuild projects

[ewaterlander]

Currently CMake and CoreBuild Makefile projects use by default launch target "Local".
If you want to connect to a remote gdb server you have to create a Managed Build debug C/C++ Remote Application launch configuration (via Run >> Debug Configurations..).

What we need is that the user can simply select a Gdb Remote target in the LaunchBar and go.

Two Gdb Remote LaunchBar targets have been created already in 2019, but they are not used. Gdb Remote Serial, and Gdb Remote TCP.

See
https://bugs.eclipse.org/bugs/show_bug.cgi?id=547831 for the description.
6a27da1 has the changes.

For me it is not completely clear what the intention was. What I think the idea was is that the user just creates and selects a Gdb Remote target in the LaunchBar, and the Launch Configuration Debug Tab will then change to like we know from the Managed Build Gdb Remote launch configuration.

The change also added a LaunchConfig provider: org.eclipse.cdt.dsf.gdb.internal.launching.GdbRemoteLaunchConfigProvider

This launchconfig provider is not used in CDT. I also don't see how it should be used for CoreBuild projects. I think, too keep it simple, you want to have just one launch configuration for a project, and the launch target sets the target (local or remote). So the launch target changes the launch configuration. This is what I also get from the short description in bug 547831.

@jonahgraham do you remember what was the idea of how to use these targets.

Any other ideas of how we should deal with different launch targets in CoreBuild projects are welcome. Please add your comments.

[jonahgraham]

I am sorry @ewaterlander - I don't know about this much. @betamaxbandit has done some work in this area and I believe he had ideas for the future here too. xref: #1000

[ewaterlander]

I am sorry - I don't know about this much. @betamaxbandit has done some work in this area and I believe he had ideas for the future here too.

OK, no problem Jonah.

We need enablement of different debug tabs based on the active launch mode and launch target. As far as I see this is not possible in the current launchConfigurationTabGroups or launchConfigurationTabs extensions to also evaluate the launch target. Only tab groups can be selected based on mode. It can be done by making a custom tab group and add tabs programmatically based on active launch target.
Also selection of the launch delegate based on launch target is needed.

I will contact @betamaxbandit

[betamaxbandit]

Hi @ewaterlander ,

Happy to discuss this.

@jonahgraham referred to #1000 . The requirements in that document that are relevant are:

IDE-82683-REQ-009
Imported CMake source project can be built - cross
User is able to import a CMake source project into an Eclipse/CDT workspace project and build it using cross-compiling toolchain.
To use other toolchains, using a Generic Launch Target allows using a different toolchain, setup in the C/C++ > Core Build Toolchains preference.

• add Debug to the Generic Launch Target setup and make it build and debug/run using the desired toolchain.

and

IDE-82683-REQ-021
Improved toolchain version support
User is able to view/select specific versions of a toolchain.
Existing API must change
Add type and version fields to the core build toolchain type.
These fields are mandatory.
These fields are exposed in the C/C++ > Core Build Toolchains preference page, in new columns labelled Type and Version.

I did not get chance to implement those for CDT12.0.0.

My vision was to improve the Generic Launch Target.
One of the deficiencies is the way the user currently selects the toolchain that it uses. I imagined a toolchain selector in the launch target. I haven't mocked any of this so far.

In my document I've refered to this as "cross" as in cross-compiled. I think this overlaps with "remote"; do you agree?

[ewaterlander]

Hi @betamaxbandit and @jonahgraham

The toolchain is related to the launch target, but this was not the reason for creating this issue.

I'm concerned about the actual launching of the built binary on different targets: on the local machine, a simulator, a remote Gdb target, or something else . I think that Gdb-Local and Gdb-Remote targets should be minimally available in vanilla CDT for CMake projects. Like these are also available for the legacy Managed Build flow (done by creating separate launch configurations).

CoreBuild projects have one single non-public launch configuration attached to it. I think that is good to keep it simple.

The biggest issue I see now is that a LaunchDelegate has no option to be enabled based on launch target. The logic to select the launch delegate is in org.eclipse.debug.internal.core.LaunchConfiguration, so this is outside CDT.

The only workaround I see is that you create your own launch delegate that calls other sub launch delegates based on the active launch target. This is not elegant.

Or we should go for multiple launch configurations? I have no idea how to handle that for CoreBuild projects.

Or you work with a single target type, and change the target with target attributes.

Summarizing: Options for selecting tabs and launch configurations based on mode and target via extensions would be the most elegant solution, but this is outside CDT. How are we going to support Local + Gdb Remote in CDT for CoreBuild projects?

[ruspl-afed]

Options for selecting tabs and launch configurations based on mode and target via extensions would be the most elegant solution, but this is outside CDT.

Perhaps, this is because "target" is not clearly defined. From what you are enumerating above

on the local machine, a simulator, a remote Gdb target, or something else

I would say that the closest Platform Debug entity is "Launch Configuration Type". And I think this is a good thing, because the set of attributes and the user interface for configuring these attributes and running delegates for each of these "targets" may differ significantly.

So, you may hide from a user the complexity of configuration with a special UI, since this is what very special "Launch Bar" is already doing. But I do not see a way to solve this "outside CDT" without articulating your idea of a "target" using existing Platform Debug entities to find what is missed there (if anything at all).

[ewaterlander]

It is indeed not fully clear (at least to me) how the launch target was supposed to be used. And then especially in the context of CDT CoreBuild projects (CMake and CoreBuild Makefile).

I'm just digging in what Doug Schaefer wrote many years ago. I think launch target is not the same as the compiler build target (x86, arm, ...). Doug left unfinished work. He created Local and Gdb-Remote launch types for CoreBuild. The Local target is only usable since the last Eclipse 2025-03/CDT 12.0 release. The Gdb-Remote type is not used. You can also not create CoreBuild launch configurations manually in the Debug Configurations wizard, because they are non-plubic. Managed Build launch configurations can be used as a workaround.

I got the idea that a launch target is to launch the same binary on different platforms. The launch configuration will adapt its tabs to the launch target. https://bugs.eclipse.org/bugs/show_bug.cgi?id=547831 This way it would be usable with the non-plublic launch configuration.
But perhaps I have the wrong idea. I would love to hear from somebody how it was supposed to be. We need to get to a general agreement on how to use the launch target.
CDT CoreBuild was inspired by the Arduino IDE. I have never used that.

[jld01]

Hi @ewaterlander, I am not familiar with the history, but it does appear that ILaunchTarget is intended for highly-generalized disambiguation of the user's intention when launching from the launchbar. I note that:

• org.eclipse.cdt.debug.core.launch.CoreBuildLaunchConfigDelegate.getBuildConfiguration(ILaunchConfiguration, String, ILaunchTarget, IProgressMonitor) uses ILaunchTarget to map to a specific CDT build configuration.
• org.eclipse.launchbar.core.DefaultLaunchConfigProvider.getLaunchConfiguration(ILaunchDescriptor, ILaunchTarget) uses ILaunchTarget to map to a specific launch configuration.

Yes, based on the static String definitions in ILaunchTarget it does appear that accommodating projects supporting different operating systems or architectures was intended as a significant use case. Selecting a certain target in the launch bar could be used to determine both an appropriate build configuration and an appropriate launch configuration (using existing launch configurations) or launch configuration type (dynamic short-lived launch configurations).

[ruspl-afed]

@ewaterlander

I had a closer look to ILaunchTarget and friends.
It looks more like a fork of Platform Debug ILaunchConfiguration (that was very sad to see).
What I can say now is that one cannot judge the purpose of ILaunchTarget without reading all the code in which it appears. However I still have an impression that the whole construct is excessive: one may just substitute the right ILaunchConfiguration instance based on the user choice in launch bar.

@jld01

org.eclipse.cdt.debug.core.launch.CoreBuildLaunchConfigDelegate.getBuildConfiguration(ILaunchConfiguration, String, ILaunchTarget, IProgressMonitor) uses ILaunchTarget to map to a specific CDT build configuration.

Yes, through comparing given ILaunchTarget with another one, attached to CDT build configuration. Don't you have a feeling that all this could have been done much easier??

org.eclipse.launchbar.core.DefaultLaunchConfigProvider.getLaunchConfiguration(ILaunchDescriptor, ILaunchTarget) uses ILaunchTarget to map to a specific launch configuration.

No, it is not. This parameter is ignored.

---

I still believe that Platform Debug ILaunchConfiguratioType gives enough to launch anything in a specific way, and the idea of ILaunchTarget is a resource-intensive dead end.
So, first we need to answer why standard Platform Debug facilities are not sufficient for this use case

[jld01]

@ruspl-afed wrote:

org.eclipse.launchbar.core.DefaultLaunchConfigProvider.getLaunchConfiguration(ILaunchDescriptor, ILaunchTarget) uses ILaunchTarget to map to a specific launch configuration.

No, it is not. This parameter is ignored.

A better example would be org.eclipse.launchbar.core.PerTargetLaunchConfigProvider.getLaunchConfiguration(ILaunchDescriptor, ILaunchTarget) which does use the ILaunchTarget parameter, but I find no concrete implementations of this class in the CDT repo. There is some related discussion at: https://bugs.eclipse.org/bugs/show_bug.cgi?id=467153 (commit f6e8b92)

[ruspl-afed]

Thank you for pointing to this discussion @jld01

Unfortunately, this does not answer the question of what problem they were going to solve by trying to "replicate a bunch of the Debug plugin launch code". In fact, this is what I see: lots of copies of the platform's debugging code with no clear purpose.

I had a look through usages, the story is almost to solve ILaunchConfiguration(Type) having ILaunchDescriptor and ILaunchTarget. Well, to be precise, the story is almost about ignoring these parameters and returning hardcoded type.
Still not clear for me why not to just use Platform Debug types, without additional layer and all this machinery.

[ewaterlander]

Hi,

@betamaxbandit and @Kummallinen have explained to me how the launchBar works. Thanks!

For CoreBuild Gdb-Remote I need a separate non-public LaunchConfiguration with its own launch delegates. The Gdb-Remote LaunchConfiguration has its own LaunchConfigurationProvider that is tied to the same LaunchDescriptorType as the CoreBuild Local LaunchConfigurationProvider. This is done in the org.eclipse.launchbar.core.launchBarContributions extension.

The LaunchConfigurationProvider is selected based on LaunchDescriptor and active LaunchTarget, via the provider's supports() method.

The user can now create a new Gdb-Remote TCP target, because it is supported. As soon as the user starts a build or launch, or presses the gear to edit the LaunchConfiguration, a new hidden (non-public) Gdb-Remote LaunchConfiguration is created on-the-fly, with a new name. The new name is not shown in the LaunchBar. You can see the new name when you edit the LaunchConfiguration, and you can find a new .launch file in the workspace area, but for the user it appears as if there is single context sensitive LaunchConfiguration.

There is no need for the launchDelegates extension to have an enablement based on the LaunchTarget, as I wrote earlier. It is solved by hidden LaunchConfigurations and the fact that LaunchDescriptor and LaunchTarget are at the top of the decision chain to select a LaunchConfiguration.

[ewaterlander]

Status update: I have it working in our own IDE based on CDT 12.0. I will create a PR.

[ewaterlander]

I ran into two issues that I wanted to fix first. See issue #1193 and PR #1207