[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
RE: [cdt-dev] Renaming "DSF Disassembly"
|
I think having multiple factories declared will be problematic. See the
javadoc for ToggleBreakpointsTargetFactory.TOGGLE_C_BREAKPOINT_TARGET_ID.
Pawel is the expert on this stuff so I'll yield to him as to how we might
be able to relocate the disassembly breakpoint support to DSF proper
while not forcing the CBreakpoint option on all DSF solutions. Perhaps it
can't be avoided and products like Workbench will need to hide the option
using capabilities/activities.
As for the IMoveToLine (etc) implementations, they seem to explicitly use
an MI run control DSF service. The base service (IRunControl) just
doesn't provide the needed functionality. I think a valid question is:
why isn't the base service being extended to handle these basic debugger
operations? Moving the PC, e.g., is certainly not a GDB-ism. I think
every C/C++ debugger in the world supports it, so shouldn't it be part of
the DSF definition?
John
At 05:40 PM 2/23/2010, Warren.Paul@xxxxxxxxx wrote:
Content-Language: en-US
Content-Type: multipart/alternative;
boundary="_000_5ABC9C306CCC574887C58E7EAC03A28C28C67AC4BENOKEUMSG02mgd_"
I'm not sure I've followed this too well,
but just pulled down the DSF-GDB plugins. I see
org.eclipse.cdt.dsf.gdb.internal.ui.breakpoints.ToggleBreakpointsTargetFactory
which looks very non-GDB specific, but specific to CBreakpoint. I
guess what you're saying is that ToggleBreakpointsTargetFactory could be
moved to DSF proper, but its plugin.xml declaration should be in DSF
implementations (GDB and EDC currently)?
<extension
point="org.eclipse.debug.ui.toggleBreakpointsTargetFactories">
<toggleTargetFactory
id="org.eclipse.cdt.dsf.gdb.ui.ToggleBreakpointsTargetFactory"
class="org.eclipse.cdt.dsf.gdb.internal.ui.breakpoints.ToggleBreakpointsTargetFactory">
<enablement>
<!-- Enable the breakpoint toggle for DSF Disassembly -->
<instanceof
value="org.eclipse.cdt.dsf.debug.internal.ui.disassembly.DisassemblyPart"/>
</enablement>
</toggleTargetFactory>
</extension>
DisassemblyToggleBreakpointsTarget looks generic enough too so I guess it
could be common.
For the runto, moveto, resumeat actions, most of it looks generic with
the exception of the adaptor factory and GDB-specific implementations of
interfaces (IMoveToLine, IMoveToAddress, etc). So other backends
(EDC) would need to implement their own adaptor factory and friends, but
would share the rest with DSF. I haven't looked closely at this at
all, but weren't these common to all CDI backends? Is there really
a techincal reason that these need to be backend-specific with DSF?
Thanks,
Warren
- From: cdt-dev-bounces@xxxxxxxxxxx
[
mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of ext John
Cortell
- Sent: Monday, February 22, 2010 10:07 AM
- To: CDT General developers list.; cdt-dev@xxxxxxxxxxx
- Subject: RE: [cdt-dev] Renaming "DSF Disassembly"
- If the code is specific to creating a CBreakpoint, then it may need
to stay out of base DSF since, as Pawel pointed out to me last week, DSF
is not, and should not, be tied to CBreakpoint. WindRiver's commercial
product, e.g., uses custom breakpoint objects. There may be a way for the
code to be in the core DSF plugins but it will need to be configured to
only appear for the specific backends that use CBreakpoint (DSF-GDB,
DSF-EDC). This sort of thing can end up being tricky; in my case, I ended
up having to make DSF-GDB use custom view model _expression_ and variable
nodes.
- Hopefully Pawel will correct me if I've misspoken, but that's my
understanding.
- John
- At 09:46 AM 2/22/2010, Warren.Paul@xxxxxxxxx wrote:
- Content-Language: en-US
- Content-Type: multipart/alternative;
-
boundary="_000_5ABC9C306CCC574887C58E7EAC03A28C28C6386B79NOKEUMSG02mgd_"
- Does that include the toggle breakpoint
support as well? John's comment indicates there is some reason for
that to be GDB specific.
-
- Thanks,
- Warren
- From: cdt-dev-bounces@xxxxxxxxxxx [
mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of ext Marc Khouzam
- Sent: Saturday, February 20, 2010 9:00 AM
- To: 'CDT General developers list.'
- Subject: RE: [cdt-dev] Renaming "DSF Disassembly"
- From a quick look, there is no technical
reasons to have these things in the gdb plugins.
- DSF being a framework, I usually add new features to DSF-GDB and once
they are proved stable,
- we move them to DSF. That is why I put those features in
DSF-GDB.
-
- But since there is an important reason
to have them in DSF, it would be very easy to move them.
- From: cdt-dev-bounces@xxxxxxxxxxx [
mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of
Warren.Paul@xxxxxxxxx
- Sent: Friday, February 19, 2010 12:00 PM
- To: cdt-dev@xxxxxxxxxxx
- Subject: RE: [cdt-dev] Renaming "DSF Disassembly"
- I just noticed that I can't set
breakpoints or run to line, etc since I don't have any gnu plugins.
Anxious to hear the reasoning for those being gdb specific.
- From: cdt-dev-bounces@xxxxxxxxxxx [
mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of ext John Cortell
- Sent: Friday, February 19, 2010 10:25 AM
- To: CDT General developers list.; CDT General developers list.
- Subject: RE: [cdt-dev] Renaming "DSF Disassembly"
- The toggle breakpoints support being GDB specific I (now) understand,
but not the line actions. Maybe Marc can shed some light on why that
stuff is housed there.
- John
- At 10:18 AM 2/19/2010, Madan Teodor-TEMADAN1
wrote:
- Content-Class: urn:content-classes:message
- Content-Type: multipart/alternative;
-
boundary="----_=_NextPart_001_01CAB17F.31AA4A45"
- For viewer to work with CDI there're the
following dependencies:
- 1. /org.eclipse.cdt.dsf.ui - the actual DSF viewer and its
dependencies org.eclipse.cdt.dsf, org.eclipse.cdt.dsf.gdb
- 2. org.eclipse.cdt.dsf.gdb.ui - for IToggleBreakpointsTargetExtension
and IMoveToLineTarget/ IResumeAtLineTarget / IRunToLineTarget
adapters
-
- Teo
- From: cdt-dev-bounces@xxxxxxxxxxx [
mailto:cdt-dev-bounces@xxxxxxxxxxx] On Behalf Of
Warren.Paul@xxxxxxxxx
- Sent: Friday, February 19, 2010 6:06 PM
- To: cdt-dev@xxxxxxxxxxx
- Subject: RE: [cdt-dev] Renaming "DSF
Disassembly"
- Given the view is still in DSF, why would we move the prefs out of
the DSP plugin?
- Well, if it's shared between DSF and
CDI, then it's really not a DSF feature and I would assume it would be in
org.eclipse.cdt.debug.ui. Is DSF required in CDT 7.0 or can vendors
ship without it if they're only using CDI?
- _______________________________________________
- 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
_______________________________________________
cdt-dev mailing list
cdt-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/cdt-dev
