Community
Participate
Working Groups
(This is a bug to track the features first raised here https://dev.eclipse.org/mhonarc/lists/cdt-dev/msg29329.html) What is desired is a way from the command line to start a debug session within Eclipse IDE. This is particularly relevant to the standalone debugger case, but is useful in all cases. This is an extension of the existing functionality of the standalone debugger. I would like to consider the use case of how the launcher can open files in running eclipses: http://help.eclipse.org/mars/topic/org.eclipse.platform.doc.isv/guide/product_open_file.htm
+1 One feature I'd like to see is the ability to double click on a core file and have it open up in a CDT debug session in either a new Eclipse session or an existing one. Not sure of how to make that work but I think we could help here.
To do this properly it seems we need to come back to what Bug 178927 was originally started out for (which when fixed resolved opening files in Eclipse, Bug 4922), i.e. a general way to send commands/events to a running eclipse and launch eclipse if it is not running already. The SWT team implemented a solution using hidden SWT windows to pass events around. As a first pass I would like to see that extended to support a more general event type. Instead of passing just a file name I would like to see it pass: - Command to run - Current working directory [1] - Command line arguments So eclipse would be launched something like: eclipse --launcher.command=org.eclipse.cdt.debug -e [EXECUTABLE] [ARGS] (I'm ignoring the problem for now of how to handle multiple arguments, but perhaps there is a restriction on -vmargs or there is only one command line argument allowed and a wrapper script handles that. I have started reviewing what the CDT standalone debugger does in that respect already) On the eclipse side there would be a new extension point to define commands that can be received. (Stretch goal is to have bi-directional support, so that --help could work, errors could be echoed back to the command line that launched them, etc). Now the problem is that I too (as many before me) can't commit to doing the full solution, including launcher integration. So for now I propose I start on something that does not require modifying launcher and core SWT and instead uses a wrapper script/program. I'll come back with a patch for a FWV when I can. We can review it from there and see if we can get this back upstream to the platform. [1] The launcher at the moment resolves the absolute path rather than leaving that to be done by the receiver, see ADJUST_PATH in eclipse.c (in rt.equinox.framework.git/features/org.eclipse.equinox.executable.feature/library)
(In reply to Doug Schaefer from comment #1) > +1 > > One feature I'd like to see is the ability to double click on a core file > and have it open up in a CDT debug session in either a new Eclipse session > or an existing one. Not sure of how to make that work but I think we could > help here. How far is it from (or is it already) possible to double-click on a core file in your workspace and have it do something sensible?
Double click on element in eclipse usually opens the element in the editor, in case of core file it will be binary editor like objdump viewer. Same as if you click on binary, however if you run click on core or binary and select debug as... something it will launch it (or launch post mortem)
I'm talking about double clicking from the operating system. Mind you the same should happen from inside Eclipse too. Opening a core file should start the debug session.
(In reply to Doug Schaefer from comment #5) > I'm talking about double clicking from the operating system. Mind you the > same should happen from inside Eclipse too. Opening a core file should start > the debug session. The reason I was asking about within Eclipse is that if double-clicking (ie opening) a core file in Eclipse could be made to work, then presumably the existing open file with the launcher would work too. And further if that was the case, then this part of the feature could be spun off into a new bug. Likewise, if any executable was opened in Eclipse and that caused it to launch rather then open in the binary editor we could support similar functionality on top of the existing SWT.OpenFile event.
Ah, true. Let's take a look at the open core file separate to this.
