Community
Participate
Working Groups
Build Identifier: M20110909-1335 To specify the default sdm debugger (gdb) path one can go to Window -> Preferences -> Parallel Tools -> Debug -> SDM -> Backend Debugger / Path to Backend Debugger. There is an extension point at org.eclipse.ptp.debug.sdm.core.SDMDebugger that makes possible to include new debuggers in the combo box of that preference and simultaneously in the combo box of the debug configuration (Debug Configuration -> Parallel Application -> Debugger -> Combobox). The problem is that it is not possible to use that window preference to specify a path for each of the debuggers. The "path to backend debugger" is just one. So apparently there is no purpose of simply adding a new backend debugger, if you cannot specify its path for it to be used. The combobox of Window Preferences containing the backend debuggers is not correlated with the field underneath it that specifies the paths of the debuggers. Reproducible: Always Steps to Reproduce: 1. Add a backend debugger using the extension point org.eclipse.ptp.debug.sdm.core.SDMDebugger 2. Go to Window -> Preferences -> Parallel Tools -> Debug -> SDM -> Backend Debugger / Path to Backend Debugger. 3. Try to specify a path for each of the debuggers in the combo box.
There are actually two paths. The "Path to backend debugger" on the preference page refers to debugger the sdm uses for low-level debug operations (e.g. gdb), not the sdm itself. The "Path to debugger executable" on the Debug tab of the launch configuration refers to the location of the sdm executable. There should ideally be an advanced field on the launch tab that copies the preferences from the preference page. The "Path to debugger executable" is independent of these and should still be set on a per-launch basis.
(In reply to comment #1) > There are actually two paths. The "Path to backend debugger" on the preference > page refers to debugger the sdm uses for low-level debug operations (e.g. gdb), > not the sdm itself. The "Path to debugger executable" on the Debug tab of the > launch configuration refers to the location of the sdm executable. There should > ideally be an advanced field on the launch tab that copies the preferences from > the preference page. The "Path to debugger executable" is independent of these > and should still be set on a per-launch basis. Hi Greg, indeed there are two paths, and we wanted to create a third-party (specific for our sdk) plug-in that set the default value of these paths. In a nutshell, our eclipse sdk is compounded of a client (provides eclipse itself), server (provides compiled sdm) and advance toolchain (provides gdb) RPMs. Assuming user has installed RPMs properly, we already known path to sdm executable (/opt/ibm/ibm-sdk-lop/sever/sdm) and gdb (/opt/at/<version>/bin/gdb) so ideally we would like to ship eclipse with these paths properly set. There is another opened bug about the "path to the debugger executable": https://bugs.eclipse.org/bugs/show_bug.cgi?id=360290 Is it possible to include such as features in upcoming PTP 6.0?
(In reply to comment #2) > > Is it possible to include such as features in upcoming PTP 6.0? If you'd like to supply a patch that provides such a feature, I could take a look at it.
Created attachment 214641 [details] Patch to add remote support to RPM using linuxtools profiling package Hi Alexander, Tried to fix what you asked. Please let me know of any problems. Thanks!
Sorry for that. I was going to submit the patch to another bug and confused myself with this window.
Created attachment 216253 [details] Added support to include new debuggers and their respective path via extension point to use with SDM.
Hi, this patch also needs to be updated to it applies to master. Thanks!
Created attachment 216320 [details] Support for adding debuggers and their path along with sdm Removed conflicts from patch. Please apply the SDM patch first. Thanks!
Created attachment 216345 [details] Support for adding debuggers and their path along with sdm Removed trailing whitespace warning.
I can't apply this patch as it contains potential NPEs and does not preserve the existing behavior. For example, you've marked the new 'path' element as optional on the extension point schema, however the code in SDMPreferencePage does this: if (sdmBackendCombo.getSelectionIndex() > 1) { sdmBackendPathText.setEditable(false); sdmBackendPathText.setEnabled(false); String[] temp = SDMDebugCorePlugin.getDefault().getDebuggerBackendsPath(); sdmBackendPathText.setText(temp[sdmBackendCombo.getSelectionIndex()]); } else { So it assumes that getDebuggerBackendsPath() returns an array with the same number of elements as there are backends. However as 'path' is optional, this may not be the case, and certainly isn't the case for the PTP SDM debugger. Also, you haven't followed the coding guidelines (you're not formatting the code as per our requirements) and you're introducing non-externalized strings. These issues will need to be addressed before I can apply the patch.
Hi Greg, I tried not to modify what was already implemented in PTP. I mean, there is already two fixed extensions including the "gdb" and "gdb-mi" debuggers in PTP, hence the "if > 1" to not modify their behavior. As they do not have a default path, I let that field as optional, and included an empty string in the getDebuggersPath method when the extension did not have a path set (that way i cant have a NPE). Do you want me to do it in a different way? I can remove the non externalized strings, but sorry to ask you that, what else is the problem? Thanks.
You can't add code that specifically assumes there will be two existing extensions. These may be removed in the future, or a third added, or whatever. Your code needs to a) preserve existing behavior, and b) do so in a way that does not hardcode any dependencies on existing or future extensions. I would suggest testing for the existence of the path element and implementing the new behavior if this element exists, otherwise retain the existing behavior.
Created attachment 216570 [details] Specify path for multiple debuggers via extension point Hi Greg, Tried to implement what you suggested, removing possible NPE and following code standard. Could you please verify if this is ok? Sorry for previous problems. Thanks.
Hi, I've taken a slightly different approach that combines the SDM path extension point with this one. You can now supply both the backend debugger path and the SDM path using the same extension point. I've also updated the SDM preference page and the SDM tab in the debugger configuration. Please take a look at this ASAP and let me know if it looks ok. I need confirmation by RC3+2 (next Tuesday) at the very latest or I will have to revert these changes.
Supposedly it would work for us. The problem is that when you specify the SDM path in the extension that uses SDMDebugger extension point it is not being loaded either in the "Window -> Preferences -> Parallel Tools -> Debug -> SDM" nor in the "Debug configurations -> Debugger tab". I couldnt find a way to specify a default debugger and if I select the debugger I created in the extension point its path is not being loaded in the gui interface.
Use the 'priority' attribute to make your backend the default. The debuggers will be listed in their priority order, with the highest value first. The standard gdb-mi backend has a priority of 10.
Closing as fixed.
Closing.
