[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [cdt-dev] Wascana default debugger
|
Actually I think it goes back to what I originally wanted, to take the environment from the active build config, i.e. the one passed down to make, and pass it on when launching gdb. I'll take a look at that if there are no objections.
On Fri, May 14, 2010 at 3:02 PM, Marc Khouzam
<marc.khouzam@xxxxxxxxxxxx> wrote:
We don't use the debugger extension point in DSF-GDB (I
actually removed that last week :-O,
because it didn't add value). The idea is that we
don't want the user to have to choose a debugger
type, it should be done automagically. Which seems to
fit with your approach.
I believe you can achieve the same thing by doing the
following:
- create a new MinGWDebuggerPage for DSF-GDB or probably
even
two, one that extends GdbDebuggerPage and the other
GdbServerDebuggerPage
(that second one is to handle remote
debugging.)
- re-use the code that figures out you should use MinGw
(the one you have in the email
below), but directly instantiate the right
MinGWDebuggerPage as we do in
org.eclipse.cdt.dsf.gdb.internal.ui.launching.CDebuggerTab#loadDynamicDebugArea
Let me know if that works.
Marc
Sent: Friday, May 14, 2010 2:43 PM
To: CDT
General developers list.
Subject: Re: [cdt-dev] Wascana default
debugger
Well, I don't want to hard code it. Here's what I have for the CDI
command factories extension:
<debugger
class="org.eclipse.cdt.debug.mi.core.MinGWDebugger"
cpu="native"
id="org.eclipse.cdt.debug.mi.core.MinGW"
modes="run,core,attach"
name="%MinGWDebugger.name"
platform="win32">
<buildIdPattern
pattern="cdt\.managedbuild\.config\.gnu\.mingw\..*">
</buildIdPattern>
</debugger>
Then in the launch shortcut and the DebuggerTab, I'd do this:
// Set the
default debugger based on the active toolchain on the project (if
possible)
ICDebugConfiguration debugConfig = null;
IProject
project = bin.getResource().getProject();
ICProjectDescription projDesc =
CoreModel.getDefault().getProjectDescription(project);
ICConfigurationDescription configDesc =
projDesc.getActiveConfiguration();
String configId = configDesc.getId();
ICDebugConfiguration[] debugConfigs =
CDebugCorePlugin.getDefault().getActiveDebugConfigurations();
int matchLength = 0;
for (int i = 0; i < debugConfigs.length;
++i) {
ICDebugConfiguration dc =
debugConfigs[i];
String[] patterns =
dc.getSupportedBuildConfigPatterns();
if (patterns != null) {
for (int j = 0; j < patterns.length; ++j)
{
if (patterns[j].length() > matchLength
&& configId.matches(patterns[j])) {
debugConfig = dc;
matchLength = patterns[j].length();
}
}
}
}
To set the debugger to the MinGWDebugger. And it was actually the
MinGWDebuggerPage that set the appropriate path to gdb.
Looking back, that's pretty ugly, but it worked. I need to figure out
something similar with the new stuff.
On Fri, May 14, 2010 at 2:25 PM, Marc Khouzam
<marc.khouzam@xxxxxxxxxxxx>
wrote:
Hi
Doug,
I'm not
sure I understood the question.
You have
logic to choose the right gdb path and you want to add it to a DSF-GDB
launch?
If that
is the case, what you need to do is
configuration.setAttribute(IGDBLaunchConfigurationConstants.ATTR_DEBUG_NAME,
<gdbPath>);
Is that
what you wanted?
Marc
Hey DSF/GDB gang (i.e. Marc ;),
One thing you'll notice if you try Wascana, is that hitting the
launch short cut doesn't give you a working launch config. As I mentioned
previously, I had logic in the short cut to pick the MinGW debugger (which
set up gdb location correctly) if the active build configuration for the
project was the MinGW toolchain.
Marc, you mentioned there was a way to do that with DSF/GDB. Can you
elaborate?
Doug.
_______________________________________________
cdt-dev
mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
