[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
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
