Gdb Manual Remote launch targets for CoreBuild projects #1222

ewaterlander · 2025-06-27T14:51:46Z

Support the Gdb Remote TCP and Serial launch targets for CoreBuild projects. A new non-public LaunchConfiguration type is added, that is working with the same launch descriptor type as CoreBuild Local projects. Also a new LaunchConfigurationProvider that supports the Gdb Remote TCP and Serial targets is added.

It makes use of the launch delegate
org.eclipse.cdt.dsf.gdb.launching.GdbTargetedLaunchDelegate, which is also used for standard GDB (DSF) Manual Remote Debugging launch configurations for TCP and Serial connections.

For the user is appears as if there is a single CoreBuild launch configuration that adapts dynamically to the launch target, while in reality there is a separate launch configuration for each target.

Fixes #1168

ewaterlander · 2025-06-27T14:56:33Z

Hi @betamaxbandit and @Kummallinen
would you like to review this?

CoreBuildGdbManualRemoteLaunchConfigProvider is at the moment a modified copy of the provider for Local. It needs further cleanup which I would like to discuss about.

With this change we will have working Gdb Remote launch targets for CMake and CoreBuild Makefile projects.

betamaxbandit · 2025-07-04T14:15:22Z

...org/eclipse/cdt/dsf/gdb/internal/launching/CoreBuildGdbManualRemoteLaunchConfigProvider.java

+
+	@Override
+	public boolean launchConfigurationChanged(ILaunchConfiguration configuration) throws CoreException {
+		// TODO Auto-generated method stub


D: remove comment

betamaxbandit · 2025-07-04T14:19:30Z

...org/eclipse/cdt/dsf/gdb/internal/launching/CoreBuildGdbManualRemoteLaunchConfigProvider.java

+
+	@Override
+	public void launchTargetRemoved(ILaunchTarget target) throws CoreException {
+		// TODO Auto-generated method stub


O: if you're sure there is nothing to do then say it in a comment.

I updated the method.

betamaxbandit · 2025-07-04T14:41:54Z

...org/eclipse/cdt/dsf/gdb/internal/launching/CoreBuildGdbManualRemoteLaunchConfigProvider.java

+ *       E.g. org.eclipse.cdt.debug.core.launch.CoreBuildGenericLaunchConfigProvider.
+ */
+
+public class CoreBuildGdbManualRemoteLaunchConfigProvider extends AbstractLaunchConfigProvider {


O: hmm, my experience of writing launch config providers for Renesas is to use ProjectPerTargetLaunchConfigProvider.
With that approach, it is expected that any values in the launch target (eg hostname, port) are copied from the launch target into the launch configuration during populateLaunchConfiguration.

Additionally we have a unique launch configuration per launch target, so in createLaunchConfiguration the name also contains the launch target ID, like this:

/* * Suffix the launch configuration with the launch target name, so its obvious to the user which one they are * using. */ String name = launchManager.generateLaunchConfigurationName(descriptor.getName()// + " " + target.getId());

When the user changes the launch target, the corresponding launch configuration is available when clicking the launchbar launch config gear. And any previously set values are shown.

Without this, I don't see the purpose of the launch target.

In this scenario, Renesas launch targets specify a target device. So maybe this approach is not appropriate when we're talking about a TCP/Serial connection.

This way of thinking for me may be so ingrained now that it's difficult for me to see any other way. Can you share your vision for this please?

Hi @betamaxbandit

I updated my code. The launch config name is now unique and target attributes are populated into the configuration.

I did not know of ProjectPerTargetLaunchConfigProvider. It is not used in CDT, except in one test.
I will look into it.

I suppose it is not critical to use ProjectPerTargetLaunchConfigProvider.
However, it does provide a getLaunch and getLaunchDescriptor method which might be useful.
Also another use of using ProjectPerTargetLaunchConfigProvider is it can be tested for using instanceof. I think this can be useful in launch classes to distinguish between a corebuild and non-corebuild launch.

At the moment a unique launch configuration is made every time the connection settings change. E.g. for a TCP target, if I change only the port number a new launch configuration is created. This means I have to re-enter in all the non Debugger tabs all non-default settings. This is perhaps a bit too much uniqueness.

Perhaps just the name of the launch target is enough.

betamaxbandit

Hi @ewaterlander ,
this looks good to me. The only minor is the extension point comment.
Some of the checks are failing - I haven't investigated those.
The other comments I've made need some more thought and probably in a future commit.

It would be good to have a manual test for this, so that at least the typical expected user flow is known and documented.

betamaxbandit · 2025-07-25T15:12:19Z

dsf-gdb/org.eclipse.cdt.dsf.gdb/plugin.xml

@@ -123,4 +140,13 @@
           </enablement>
      </configProvider>
   </extension>
+   <extension


O: this extension point could be merged with the one above.

betamaxbandit · 2025-07-25T15:13:31Z

...org/eclipse/cdt/dsf/gdb/internal/launching/CoreBuildGdbManualRemoteLaunchConfigProvider.java

+		return workingCopy.doSave();
+	}
+
+	private String getTargetConfigKey(ILaunchTarget target) {


I like this method and the one in CoreBuildGenericLaunchConfigProvider

betamaxbandit · 2025-07-25T15:18:00Z

...org/eclipse/cdt/dsf/gdb/internal/launching/CoreBuildGdbManualRemoteLaunchConfigProvider.java

+ *       E.g. org.eclipse.cdt.debug.core.launch.CoreBuildGenericLaunchConfigProvider.
+ */
+
+public class CoreBuildGdbManualRemoteLaunchConfigProvider extends AbstractLaunchConfigProvider {


I suppose it is not critical to use ProjectPerTargetLaunchConfigProvider.
However, it does provide a getLaunch and getLaunchDescriptor method which might be useful.
Also another use of using ProjectPerTargetLaunchConfigProvider is it can be tested for using instanceof. I think this can be useful in launch classes to distinguish between a corebuild and non-corebuild launch.

betamaxbandit · 2025-07-25T15:36:00Z

...org/eclipse/cdt/dsf/gdb/internal/launching/CoreBuildGdbManualRemoteLaunchConfigProvider.java

+		String targetTypeId = target.getTypeId();
+		if (targetTypeId.equals(GDBRemoteTCPLaunchTargetProvider.TYPE_ID)) {
+			String host = target.getAttribute(IGDBLaunchConfigurationConstants.ATTR_HOST, EMPTY);
+			String port = target.getAttribute(IGDBLaunchConfigurationConstants.ATTR_PORT, EMPTY);
+			workingCopy.setAttribute(IGDBLaunchConfigurationConstants.ATTR_REMOTE_TCP, true);
+			workingCopy.setAttribute(IGDBLaunchConfigurationConstants.ATTR_HOST, host);
+			workingCopy.setAttribute(IGDBLaunchConfigurationConstants.ATTR_PORT, port);
+		}
+		if (targetTypeId.equals(GDBRemoteSerialLaunchTargetProvider.TYPE_ID)) {
+			String serialPort = target.getAttribute(IGDBLaunchConfigurationConstants.ATTR_DEV, EMPTY);
+			String baudRate = target.getAttribute(IGDBLaunchConfigurationConstants.ATTR_DEV_SPEED, EMPTY);
+			workingCopy.setAttribute(IGDBLaunchConfigurationConstants.ATTR_REMOTE_TCP, false);
+			workingCopy.setAttribute(IGDBLaunchConfigurationConstants.ATTR_DEV, serialPort);
+			workingCopy.setAttribute(IGDBLaunchConfigurationConstants.ATTR_DEV_SPEED, baudRate);
+		}


Good to see you are copying the values from the launch target to the launch config here.

If the user subsequently changes the values in the launch target, they are not be updated in the launch configuration. More thought is needed to handle this, maybe in another commit...

Perhaps there should be a new ILaunchConfigurationProvider2 added, which has launchTargetChanged. I'm just thinking aloud here. Maybe this is called in 2 places:

When the launch config is opened again.

During a launch, which allows the launch config to be synchronised with the launch target.

Also related to this comment is another issue.

The Type control and other controls for TCP and Serial should be disabled when using a targetted launch, because now these values can be specified in 2 places; the launch target and the launch config. Which one takes precedence? I think the launch target values should. Therefore the user should not be aloud to change them in the launch config.

Maybe to assist the user when the controls are greyed out, there should be a helpful hint to change them in the launch target, in a tooltip or message somewhere

When using a non-targetted launch (ie the regular Debug Configurations dialog with delegate C/C++ Remote Applications using "GDB (DSF) Manual Remote Debugging Launcher"), the controls should be enabled.

A launch target can be used for multiple launch configurations. You would have to keep all of them in sync.

Core Build launch configurations are not public, they can only be launched from the launch bar, not from the regular Debug Configurations dialog. The launch target values take precedence over the launch configuration values. The controls and fields can be greyed out as you suggested, when the launch configuration of Core Build type. Editing does not make sense, because it will always be overruled by the launch target.

I added a commit that disables the fields in the launch configuration when the type is Core Build GDB Remote.

Support the Gdb Remote TCP and Serial launch targets for CoreBuild projects. A new non-public LaunchConfiguration type is added, that is working with the same launch descriptor type as CoreBuild Local projects. Also a new LaunchConfigurationProvider that supports the Gdb Remote TCP and Serial targets is added. It makes use of the launch delegate org.eclipse.cdt.dsf.gdb.launching.GdbTargetedLaunchDelegate, which is also used for standard GDB (DSF) Manual Remote Debugging launch configurations for TCP and Serial connections. For the user is appears as if there is a single CoreBuild launch configuration that adapts dynamically to the launch target, while in reality there is a separate launch configuration for each target. Also cleanup up a bit CoreBuildGenericLaunchConfigProvider and fixed a bug in launchTargetRemoved(). Fixes eclipse-cdt#1168

Launch Target settings have precedence over Launch Configuration settings. Multiple Launch Configurations can use the same Launch Target. Disable settings controlled by the Launch Target to avoid inconsistent settings. For non-CoreBuild GDB remote launch configurations the settings remain editable. These launch configurations can be launched without launch bar.

ewaterlander · 2025-08-22T08:01:33Z

I'm going to add documentation too.

ewaterlander · 2025-09-02T09:33:56Z

Hi @betamaxbandit , would you like to review my last commit "New launch configuration name based on target name."

betamaxbandit · 2025-09-02T13:26:44Z

Hi @betamaxbandit , would you like to review my last commit "New launch configuration name based on target name."

Hey @ewaterlander , nice1 for the update. I'll review it soon.

The new launch configuration name is only based on the target name and the type (tcp or serial). Changing a connection parameter will not result in a new launch configuration.

github-actions · 2025-09-03T12:32:14Z

Test Results

636 files 636 suites 35m 34s ⏱️
11 440 tests 11 295 ✅ 144 💤 1 ❌
11 439 runs 11 296 ✅ 142 💤 1 ❌

For more details on these failures, see this check.

Results for commit f14f4a4.

ewaterlander · 2025-09-03T14:27:37Z

License check is failing because ClearlyDefined servers are offline.
One failing test. Looks unrelated to me.
I try again later.

ewaterlander mentioned this pull request Jul 4, 2025

GDB Remote launch targets load attributes when editing. #1207

Merged

betamaxbandit reviewed Jul 4, 2025

View reviewed changes

ewaterlander force-pushed the gdb_remote_target branch from c85626c to ddd704c Compare July 18, 2025 15:39

betamaxbandit reviewed Jul 25, 2025

View reviewed changes

ewaterlander force-pushed the gdb_remote_target branch 2 times, most recently from 81b77e9 to aa54039 Compare August 21, 2025 11:43

ewaterlander force-pushed the gdb_remote_target branch from aa54039 to aa50b9e Compare August 21, 2025 12:38

ewaterlander requested a review from betamaxbandit August 21, 2025 12:39

Documentation Core Build debug remote target.

3afacff

New launch configuration name based on target name.

f14f4a4

The new launch configuration name is only based on the target name and the type (tcp or serial). Changing a connection parameter will not result in a new launch configuration.

ewaterlander force-pushed the gdb_remote_target branch from aa16fd1 to f14f4a4 Compare September 3, 2025 11:44

Gdb Manual Remote launch targets for CoreBuild projects #1222

Are you sure you want to change the base?

Gdb Manual Remote launch targets for CoreBuild projects #1222

Uh oh!

Conversation

ewaterlander commented Jun 27, 2025

Uh oh!

ewaterlander commented Jun 27, 2025

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

betamaxbandit left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

ewaterlander commented Aug 22, 2025

Uh oh!

ewaterlander commented Sep 2, 2025

Uh oh!

betamaxbandit commented Sep 2, 2025

Uh oh!

github-actions bot commented Sep 3, 2025

Test Results

Uh oh!

ewaterlander commented Sep 3, 2025

Uh oh!

Uh oh!