#48 Support for project-less debugging
Since CDT 8.0 the feature referred to as projectless (project-less) debugging has been supported:
https://wiki.eclipse.org/CDT/User/NewIn80#Project-less_debugging
Using default values the Segger and Openocd launch configurations do not support projecless debugging. This is because the "GDB client setup > Executable " uses a value of ${cross_prefix}gdb${cross_suffix}. These variables are defined on a project level. If no project is specified then those variables are not defined.
A workaround to this is to use an absolute path.
However, if the user defined those variables in the workspace build variables (Window > Preferences > C/C++ > Build > Build Variables) then the launch would work without a project being specified.
I propose a change to:
ilg.gnuarmeclipse.debug.gdbjtag.jlink.Utils.getLaunchEnvironment(ILaunchConfiguration)
where if the project is null or empty then the workspace build variables are returned, rather than null at the moment.
I could have a go at providing a patch for this if I can figure out how to get the workspace build variables.
cheers john
in principle we can use workspace variables, but I need help to understand what would be the use case. to debug executables built outside Eclipse? in this case the question is who will know how to manually define so many variables in the workspace?
Great.
I was thinking that my company's product could define default cross_prefix and cross_suffix, so that debugging can be accomplished without having any projects at all in the workspace, for example.
I'm not aware of any other variables that would need to be defined.
ok, if you define the variables in your environment it should be no problem.
please provide the patch you need and I'll apply it.
OK, thanks. I tried to quickly knock something up; I managed to construct some of the environment without a configuration, but I'm still missing something so it needs a little more work. I'll get back onto this when I get time.
cheers john
Hi Liviu,
I've made some changes to allow projectless debugging. When no project is specified in the launch configuration the macros in Debugger tab > J-Link GDB Server Setup > Executable (${jlink_path}/JLinkGDBServerCL) and GDB Client Setup > Executable (${cross_prefix}gdb${cross_suffix}) are retrieved from the global workspace environment.
This relies on the user defining the environment variables jlink_path, cross_prefix and cross_suffix. This should be done in the Build Environment page (Window > Preferences > C/C++ > Build > Environment) and not Build Variables page as stated in the original support request description.
I attach a patch to the ilg.gnuarmeclipse.debug.gdbjtag.jlink plugin. The same changes will be necessary for openocd. If you could review the patch and if you're happy I could provide another patch for the openocd plugin if you wish.
I've used a few internal classes to get at the environment. I've intentionally not added @SuppressWarnings("restriction") so that you're aware of them.
cheers john
Incidentally, I found that if cross_prefix, etc, is defined in global Build Environment page and the user decides to launch a project based session the precedence of variables behaves as one would hope. That is, when using a project launch the cross_prefix value from the project configuration will be used, over the Build Environment page.
sorry, I'm again missing the point. your patch is extensive, but it looks it is solving an artificial problem.
the macros were introduced there to accommodate multiple toolchains, but in your case you have only one custom toolchain. for such special cases you can safely edit the debug configuration and directly use arm-none-eabi-gdb (or whatever name you have), without the need for any macros, local or global.
Hi Liviu,
Thanks for looking at the patch and considering it. However, I don't see it as an artificial problem for a number of reasons:
Out of the box experience. When the user wants to debug without a project the default values that we set in our product for variables like cross_prefix mean that the launch will work "out of the box". The user won't have to define those values if they are happy with the defaults.
Supports portability of projects. If absolute paths are inserted in launch configuration fields (eg gdb server Executable) when the user runs on a different environment (eg another machine) those paths all need updating. If multiple projects/configurations are used this could be considerable work. Having the facility to update a single variable in the environment page makes the process much easier.
Supports product updates. If the version of the SEGGER tools is updated, and the new version is located in a new directory (as is the default installation behaviour) the absolute path will require updating. Again, as above, updating a single variable eases this.
Supports multiple toolchains. Some of our users do want to use their own toolchains. Having the ability to alter the cross_prefix/suffix from a single place eases switching toolchains.
Is it possible that this extra information about our product usage changes your view at all?
cheers john
you are basically right, but you are mixing things. currently (after the latest changes) the jlink_path, jlink_gdbserver, openocd_path, openocd_executable are stored in a workspace preference file (.metadata/.plugins/org.eclipse.core.runtime/.settings/org.eclipse.core.variables.prefs) and are editable in the Run/Debug -> String Substitution window.
cross_prefix, cross_suffix and all other from this family are dynamically generated from the project configuration.
the persistent defaults for the debugging plug-ins are also stored as workspace preference files (.metadata/.plugins/org.eclipse.core.runtime/.settings/ilg.gnuarmeclipse.debug.gdbjtag.[jlink|openocd].prefs)
if you want different defaults then the one provided, you can easily programatically change the values in these storage, or, at limit, we can make the defaults externally configurable with some property files, similar to the toolchain name/path.
so I'm not advocating on using any absolute paths, I just don't understand why you would need to use cross_prefix/suffix in a project-less debug configuration, which is a very rarely used case. in your opinion, are we talking only about cross_prefix/suffix, or are there other macros also involved?
if you can explain this, and also explain how it should be solved, I might reconsider.
nope. you are missing something, ${cross_prefix} is only an executable name prefix, like 'arm-none-eabi-", and does not include any path part, the path is taken from different definitions.
Hi Liviu,
I see where you're coming from now.
For the simple reason that they are the default values in a new launch configuration! That's all.
You are correct; the 2 main fields that are relevant are both Executable fields in the Debugger tab.
For the 1st, gdbserver executable field, it sounds like your introduction of "${jlink_path}/${jlink_gdbserver}" may solve the issue.
For the 2nd, gdbclient executable field, I assume the defaults of "${cross_prefix}gdb${cross_suffix}" remain and are unresolvable if a project is not specified?
Do you expect variables from the Run/Debug -> String Substitution window to be resolved even though there is no project specified?
I think I may be missing a fundamental Eclipse understanding. I don't know the benefits of using "Preferences > Run/Debug -> String Substitution" over "Preferences > C/C++ > Build > Environment". Can you explain?
cheers john
just to be sure you got it right: for jlink/opneocd, the default values in a new launch configuration are exactly the values you used in the previous configuration. in other words, most values are persistent in the workspace.
so all your effort is for the very first use of the plugins, in a very seldom use situation.
from what I see in the TabDebugger.java, the getGdbClientCommand(), first the Run/Debug -> String Substitution variables are processed, then the project variables.
the "Run/Debug -> String Substitution" are macros for the entire workspace, while the "Preferences > C/C++ > Build > Environment" variables are simply passed to new processes via the environment list.
Ah, it seems I've been "barking up the wrong tree"; String Substitution seems the way to go with this sort of thing.
I just tried your new changes. In Run/Debug -> String Substitution I defined cross_prefix and cross_suffix and attempted projectless debug.
I've got partial success. The above macros are expanded correctly without a project; great! But there is still a little bit of work to do inside Utils.getGDBVersion() because getLaunchEnvironment() returns null env when the config is null.
Looks like just part of my patch will solve this.
please resubmit a shorter patch that fixes this.
ok will do.
Looks like I will want to programmatically define cross_prefix and cross_suffix in String Substitutions for the projectless case. Have you got a pointer on that you can give me please?
you can take a look at how the jlink&openocd plug-ins define their macros.
Ah I see there's an ext point for it:
<extension point="org.eclipse.core.variables.valueVariables">
that's Eclipse, there must be an ext point for almost everything :-)
New, smaller patch which assumes launch configuration macros are defined in Run/Debug -> String Substitution.
rgds john
ok, I guess I made it work, using an absolute path for the executable.
Patch for equivalent functionality in the openocd plugin.
both patches applied. new pre-release version on updates-test.
Tested using updates-test and both openocd and jlink project-less launches work!
Thanks very much for persevering with this.