Thanks Darin.
One question. Do you recommend listening to the java breakpoints via a
BreakpointManager.addbreakpointlistener() registration (on a DebugTarget
basis)?
rpm
-----Original Message-----
From: platform-debug-dev-bounces@xxxxxxxxxxx
[mailto:platform-debug-dev-bounces@xxxxxxxxxxx] On Behalf Of Darin
Wright
Sent: Wednesday, August 30, 2006 1:40 PM
To: Eclipse Platform Debug component developers list.
Cc: platform-debug-dev-bounces@xxxxxxxxxxx; Eclipse Platform Debug
component developers list.; dsdp-dd-dev@xxxxxxxxxxx
Subject: RE: [platform-debug-dev] Editor adaptors for breakpoint
toggling
Rick,
I'm finally catching up after being away on vacation...
I'm not sure I fully understand the scenario here, but I think it goes
something like this: you have java files that sometimes run on your
special hardware, and are sometimes run by a standard JVM as a
simulation.
I assume that when you run them on your hardware you have your own
implementation of a debug target, etc? And when you run as a simulation,
you use the SDK's implementation of the Java debug target?
First, an editor can only have a single "toggle breakpoint adapter"
registered with it. This is the way adapters work - there can only be
one
adapter of a given type registered with any given implementation class
or
interface. So, you cannot override the adapter provided to the Java
editor
unless you remove the "org.eclipse.jdt.debug.ui" plug-in that
contributes
it.
However, it sounds like a solution would be to allow the JDT's
breakpoint
adapter to create the breakpoints, as it does already. Then when you run
as a simulation on a standard JVM, the breakpoints will just work as
they
should. When you run on your hardware, I assume that you will have a
debug
target implementation that could listen for Java breakpoints and
consider
existing (deferred) breakpoints at startup. Your debug target will just
need to use the Java breakpoint API in order to translate/install them
into the underlying hardware. I think this is what Pawel has suggested
as
well.
Darin Wright
"Rick Marion" <rick@xxxxxxxxxx>
Sent by: platform-debug-dev-bounces@xxxxxxxxxxx
08/23/2006 10:27 AM
Please respond to
"Eclipse Platform Debug component developers list."
<platform-debug-dev@xxxxxxxxxxx>
To
"Eclipse Platform Debug component developers list."
<platform-debug-dev@xxxxxxxxxxx>, <dsdp-dd-dev@xxxxxxxxxxx>
cc
Subject
RE: [platform-debug-dev] Editor adaptors for breakpoint toggling
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
_______________________________________________
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
