RE: [platform-debug-dev] Editor adaptors for breakpoint toggling

["Rick Marion" <rick@xxxxxxxxxx>]

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