Community
Participate
Working Groups
In the debug launch configuration dialog, changing between "GDB (DSF) Create Process Launcher" and "Standard Create Process Launcher" breaks the CDI launch. Steps to reproduce. - Create a helloworld project - Create a launch configuration (1) [OK] - Go to the "Debugger" tab. - "Select Other..." launcher + Use configuration specific setting + Select CDI (2) [OK] - Go to the "Debugger" tab. - "Select Other..." launcher + Select DSF (3) [OK] - Go to the "Debugger" tab. - "Select Other..." launcher + Select CDI (4)[Broken] - Launch configuration is now broken... There's a Red X on the Debugger Tab with the error "[Debugger]: No debugger available". True enough, no debugger is selected on the debugger tab. If I persist the launch in the workspace, I can see the following changing: Between (1) & (2): - Whole bunch of attributes added - org.eclipse.cdt.launch.DEBUGGER_ID: gdb -> org.eclipse.cdt.debug.mi.core.CDebuggerNew - <mapAttribute key="org.eclipse.debug.core.preferred_launchers"> <mapEntry key="[debug]" value="org.eclipse.cdt.cdi.launch.localCLaunch"/> </mapAttribute> Between (2) & (3): - <mapEntry key="[debug]" value="org.eclipse.cdt.cdi.launch.localCLaunch"/> -> <mapEntry key="[debug]" value="org.eclipse.cdt.dsf.gdb.launch.localCLaunch"/> Between (3) & (4): - org.eclipse.cdt.launch.DEBUGGER_ID: org.eclipse.cdt.debug.mi.core.CDebuggerNew -> gdb - <mapEntry key="[debug]" value="org.eclipse.cdt.dsf.gdb.launch.localCLaunch"/> -> <mapEntry key="[debug]" value="org.eclipse.cdt.cdi.launch.localCLaunch"/>
We also have launches in our repository which seem busted in Helios. I guess when the old debuggers were removed there wasn't / isn't an automatic conversion of the debugger ID. This is not very nice from a backwards compatibility POV. In the repo there's: <stringAttribute key="org.eclipse.cdt.debug.mi.core.commandFactory" value="org.eclipse.cdt.debug.mi.core.standardCommandFactory"/> <stringAttribute key="org.eclipse.cdt.launch.DEBUGGER_ID" value="org.eclipse.cdt.debug.mi.core.CDebugger"/> Both of which have changed to: <stringAttribute key="org.eclipse.cdt.debug.mi.core.commandFactory" value="org.eclipse.cdt.debug.mi.core.standardLinuxCommandFactory"/> <stringAttribute key="org.eclipse.cdt.launch.DEBUGGER_ID" value="org.eclipse.cdt.debug.mi.core.CDebuggerNew"/> Have we broken all launches which were created with a previous version of CDT?
(In reply to comment #0) > In the debug launch configuration dialog, changing between "GDB (DSF) Create > Process Launcher" and "Standard Create Process Launcher" breaks the CDI launch. > Steps to reproduce. > - Create a helloworld project > - Create a launch configuration (1) [OK] > - Go to the "Debugger" tab. > - "Select Other..." launcher > + Use configuration specific setting > + Select CDI (2) [OK] > - Go to the "Debugger" tab. > - "Select Other..." launcher > + Select DSF (3) [OK] > - Go to the "Debugger" tab. > - "Select Other..." launcher > + Select CDI (4)[Broken] > - Launch configuration is now broken... > There's a Red X on the Debugger Tab with the error "[Debugger]: No debugger > available". True enough, no debugger is selected on the debugger tab. When you say 'broken', to you mean that the user must select a [Debugger], or do you mean that the user can not recover at all? I didn't find that having to manually select a debugger was a major problem, since the user is actually making 'advanced' changed, by selecting the type of debugging integration. But I agree it would be nicer to automate this more. The problems with our 'shared' launches are that: 1- Most launch properties are shared between DSF-DGB and CDI (and EDC), but the valid values for these properties are not the same for each debugger integration. 2- Some launch properties are unique to a debugger integration 3- When changing the type of debugger integration, the launch configuration already exists, so no defaults are being set A similar problem happened when using the same launch config to Run and then to Debug (Bug 281970). What would be nice is if we had a way to convert a DSF launch config to a CDI launch config and vice versa. We could then remove unused properties, set missing ones, etc. Each tab would be responsible to do that. The problem is that I haven't found a way for a tab to know that it is being created due to a switch in launch delegate type. Maybe we can try to add that into the platform. Currently, if a launch config is new, the tab is created and setDefaults() is called. If the launch config exists, initializeFrom() is called instead. What would help is to have setDefaults() called when a launch delegate changes (similar to what we did in Bug 281970). For such a solution to be nice, we shouldn't blindly reset all defaults, but we should do this 'conversion' from whatever values are in the launch config, to corresponding values for the new launch delegate type. > If I persist the launch in the workspace, I can see the following changing: Yes, properties are not all shared, and values are not all the same between launch delegates.
(In reply to comment #1) > We also have launches in our repository which seem busted in Helios. I guess > when the old debuggers were removed there wasn't / isn't an automatic > conversion of the debugger ID. This is not very nice from a backwards > compatibility POV. > In the repo there's: > <stringAttribute key="org.eclipse.cdt.debug.mi.core.commandFactory" > value="org.eclipse.cdt.debug.mi.core.standardCommandFactory"/> > <stringAttribute key="org.eclipse.cdt.launch.DEBUGGER_ID" > value="org.eclipse.cdt.debug.mi.core.CDebugger"/> > Both of which have changed to: > <stringAttribute key="org.eclipse.cdt.debug.mi.core.commandFactory" > value="org.eclipse.cdt.debug.mi.core.standardLinuxCommandFactory"/> > <stringAttribute key="org.eclipse.cdt.launch.DEBUGGER_ID" > value="org.eclipse.cdt.debug.mi.core.CDebuggerNew"/> > Have we broken all launches which were created with a previous version of CDT? Could this be caused by Bug 309023? I don't recall changes to standardCommandFactory though but I could be wrong.
(In reply to comment #2) > When you say 'broken', to you mean that the user must select a [Debugger], or > do you mean that the user can not recover at all? In both cases the user can recover by selecting a different debugger. I guess the removal of the debugger ids is more problematic than the DSF->CDI change -- this is just something I noticed while playing with DSF v CDI. I had a bug filed here by a power user who wasn't aware that the fix for: "[Debugger]: No debugger available" is to switch to the Debugger tab and reselect a valid debugger. Perhaps the simplest thing to do in this case is for the debugger selection in initializeFrom() to force select the default available debugger if the specified debugger can't be found. Given that this requires manual intervention, and the launch configuration can't be launched without a valid debugger, re-setting this to the default would quietly resolve the issue without negative effects? I can understand that many of the launch attributes are shared. This is useful for arguments, gdb options etc. However in the case of CDI/DSF specific attributes which aren't compatible between the two debuggers, does it make sense to share this attribute? Ideally any setting which isn't applicable to an the alternative debugger back-end shouldn't be touched by the alternative debugger...
(In reply to comment #3) > Could this be caused by Bug 309023? > I don't recall changes to standardCommandFactory though but I could be wrong. It looked like that bug removed the old debugger id. Going back in time "gdb/mi" seems to have been the default for ages. I was worried that there would be a load of broken launch configs in our repositories, but this doesn't look likely.
(In reply to comment #4) > (In reply to comment #2) > > When you say 'broken', to you mean that the user must select a [Debugger], or > > do you mean that the user can not recover at all? > > In both cases the user can recover by selecting a different debugger. > > I guess the removal of the debugger ids is more problematic than the DSF->CDI > change -- this is just something I noticed while playing with DSF v CDI. > I had a bug filed here by a power user who wasn't aware that the fix for: > "[Debugger]: No debugger available" > is to switch to the Debugger tab and reselect a valid debugger. > > Perhaps the simplest thing to do in this case is for the debugger selection in > initializeFrom() to force select the default available debugger if the > specified debugger can't be found. Given that this requires manual > intervention, and the launch configuration can't be launched without a valid > debugger, re-setting this to the default would quietly resolve the issue > without negative effects? Sounds good. In setDefaults() there is logic to set the debugger based on the toolchain, I think that is what we should do in initializeFrom() when the debuggerId is wrong. > I can understand that many of the launch attributes are shared. This is useful > for arguments, gdb options etc. However in the case of CDI/DSF specific > attributes which aren't compatible between the two debuggers, does it make > sense to share this attribute? Ideally any setting which isn't applicable to > an the alternative debugger back-end shouldn't be touched by the alternative > debugger... That is true. The disadvantage is that the launch config file will get 'polluted' with a bunch of properties that are no longer valid (e.g., the DSF properties will stay in the launch file even though the launch is now a CDI launch). Ultimately, this may cause a bit of confusion even in the UI because a DSF launch that is converted to a CDI launch, would retain it's old DSF values, and if the CDI launch is changed back to DSF 3 months later, the user may be surprised to find different values than what the defaults usually bring up. I think we should go towards a solution that gives the user a correct and most intuitive experience when changing between debugger integrations; so I don't mind the sharing of properties, as long as we avoid annoying cases like the one your reported.
