[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
RE: [cdt-dev] Renaming "DSF Disassembly"
|
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
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