[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[dsdp-dd-dev] Re: [platform-debug-dev] Editor adaptors for breakpoint toggling
|
Hi Rick,
If you allow your users to set breakpoints within your disassembly
editor then you will still need to have your own breakpoint objects, and
the corresponding IToggleBreakpointTarget object for your own
disassembly editor. In this case your debugger implementation will need
to handle both the JDT breakpoints and your own breakpoints. I'm not
sure if this is the user experience you are after, but without extending
and/or modifying JDT you have limited options.
Good luck
-Pawel
Rick Marion wrote:
Thanks Pawel,
I can try your suggestion. My concern was that since I wasn't
completely replacing the IToggleBreakpointsTarget adapter that there
would be a hole in the functionality.
rick
-----Original Message-----
From: platform-debug-dev-bounces@xxxxxxxxxxx
[mailto:platform-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Pawel Piech
Sent: Tuesday, August 22, 2006 5:35 PM
To: Eclipse Platform Debug component developers list.;
dsdp-dd-dev@xxxxxxxxxxx
Subject: Re: [platform-debug-dev] Editor adaptors for breakpoint
toggling
Hi Rick,
Although I'm not entirely sure I comprehend your configuration, I'm
going to take a shot at answering it anyway.
In my opinion, your best bet is to pursue something similar to you
strategy of creating breakpoints that are duplicates of of JDT
breakpoints ("For instance, we could let the java editor set its own
breakpoints, and then at launch time we would create our version of the
breakpoint."), except I wouldn't create duplicates, but instead have
your debugger engine install breakpoints based on the original JDT
breakpoints.
Beyond that, to achieve the features you seek, you would probably be
need to extend the JDT debugger implementation. For example, to
prevent JDT from installing the breakpoints before your debugger engine
had a chance to have a look at them, you would need some flag that JDT
would read. Alternatively, you could try adjusting the enabled/disabled
setting of the breakpoint, but it would probably be an error-prone
solution.
Cheers
Pawel
P.S. I cross-posted to a mail alias for Device Debugging (DSDP/DD)
project where we deal specifically with remote/hardware debugging
issues.
Rick Marion wrote:
/Hello,/
/I'm in the process of developing a debugger for a hardware platform
our company has developed. The platform debugger understands both java
and assembly as the source language(s). For assembly, we have our own
file extension to direct the editor and invoke our runtime adapter
factory for breakpoint creation, etc when we toggle for breakpoints in
the ruler. However, for java source we cannot do this since we want
only java projects with a nature we've supplied to be intercepted and
processed with our breakpoint code. Java in projects without our
nature should be directed to the standard JDT. Furthermore, in some
instances, Java code with our nature would still be directed to the
JDT/JVM if we're launching a simulation. The "Eclipse Debugger How-to"
suggests supplying a new source editor and adapting it. Will this
mechanism work when multiple plug-ins registering different editors
but still associated to edit files of the same extension, i.e. .java?
/
/If we have to write our own editor, we want to inherit all the
features of the existing java editor with the exception of setting
breakpoints. We want to be able to set our own breakpoints. When I say
all the features, I even mean the parsing of the java code and the
production of the AST. Is inheriting all the java editor features as
easy as extending JavaEditor even though it's internal, or are we in
for a lot of work?/
/We've considered alternatives. For instance, we could let the java
editor set its own breakpoints, and then at launch time we would
create our version of the breakpoint. Our version of the breakpoint
would never be registered with the BreakpointManager. If the user
deletes a breakpoint from a launched program we could listen to the
BreakpointManager to know when we should delete our version of the
breakpoint. /
/Ultimately, we want to defer the decision of capturing the toggle and
setting breakpoints in our hardware or setting the breakpoint in the
JVM to happen dynamically at toggle time, not editor configuration
time or plug-in install time. For instance, if we're running an
application in simulation mode, we want to send the toggle to the
standard JVM handler, if we've launched a session that communicates
with our hardware, we want to send breakpoint to our hardware. This
bring up the issue of deferred breakpoint installation. Prior to
launch, we don't know where to direct the breakpoint (JVM or our
hardware). When we eventually launch we'll be able to direct all the
breakpoints to our hardware, but won't the JVM already have attempted
to install the breakpoint requests? How can we either circumvent the
JVM from installing the breakpoints or backout the install requests./
/Is this possible or are there other mechanisms we should be using to
direct the toggle action?/
/ /
/Thanks,/
/ /Rick
------------------------------------------------------------------------
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
_______________________________________________
platform-debug-dev mailing list
platform-debug-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/platform-debug-dev
