| Re: [Dltk-dev] breakpoints for remote debugging |
My thought on this problem is that path mapping should be done in the DLTK DBGP implementation - when breakpoints are set the path should be translated from local to remote, after receiving stack trace the reverse translation should take place.
This approach does not require changes to the editing files and setting breakpoint - the changes are internal to the debugger protocol.
Ideally remote debugger could inherit from the local debugger and just override some methods.
What do you think?
Jae Gangemi wrote:
don't you just hate it when a plan falls apart...grr!
turns out that while this approach works for breakpoints that are set once the debugging session has started, it doesn't work for 'deferred' breakpoints. i think the trick to solving this issue is going to be to replace the mapped path right before the dbgp breakpoint commands are issued. if it's possible to map the file when it's looked up, it should be possible to map it back on the way out.
still investigating this and will post back later, i got caught up on a bug with the ScriptSourceLookupParticipant not matching against interpreter libraries (which caused it to fall back to looking up the source via dbgp).
On Tue, Jun 24, 2008 at 10:16 AM, Jae Gangemi <jgangemi@xxxxxxxxx <mailto:jgangemi@xxxxxxxxx>> wrote:
that's an interesting approach, but unfortunately, one that will
not work for me (or probably any other language that uses the an
active state engine).
the marker approach seems to be the least intrusive - i'd like
it better if i could wrap the mapped IFile object in some kind of
delegate that could be smart enough to know when to return the
stack frame path and when to return the local path, but that
doesn't seem to be a workable option - on the surface it seems
possible, but i still want to be able to edit the mapped source
and have the changes save in my local workspace (the only way to
have the remote app see them is to redeploy the code) and i have a
feeling that would no longer work w/ the delegate approach (or it
would be extremely complicated).
futher investigation indicates that i really need to clear the
marker in-between each debugging launch - there's no reason why a
user couldn't attempt to run the same mapped resource in a local
debug session. i think may be possible to enhance the
RemoteSourceLookupDirector so it tracks the resources and/or
markers it creates and have it clear them when it is disposed.
i'm going to play around some more with this tonight and see
where it gets me - there are a couple of sub cases that i want to
try out and see how they behave and that will require clearing the
markers.
On Tue, Jun 24, 2008 at 3:18 AM, Johan Compagner<jcompagner@xxxxxxxxx <mailto:jcompagner@xxxxxxxxx>> wrote:
You are already working with compiled/sourceless code so i
guess you cant do what i do in _javascript_
But what we do is we send over the path of the script that the
DBGP debugger has to the remote application
And there we compile it with the right filename/linenumber
from the eclipse side, the compileFunction doesnt read the
file itself in _javascript_ you just give th src as text with
the filename and linenumber of that source
And then it is synced perfectly.
johan
On Tue, Jun 24, 2008 at 4:16 AM, Jae Gangemidltk-dev@xxxxxxxxxxx <mailto:dltk-dev@xxxxxxxxxxx><jgangemi@xxxxxxxxx <mailto:jgangemi@xxxxxxxxx>> wrote:
hello all -
i started looking into how to get this working again and
have come up with a potential solution (and some blocking
issues), just to recap the use case i'm trying to solve
here...
i need to be able to debug perl code that is embedded
within another application. remote debugging already
supports the ability to 'map' remote resources into their
counterparts in the local workspace (this is done if the
'remote working directory' is set in the remote launch
config - if the resource does not exist, it is looked up
using the dbpg 'source' command). the problem setting
breakpoints against the mapped resource is that the path
to the file in the local workspace may not match what the
'fileuri' attribute that is returned when a connection has
been established. in order to have the dbgp engine respect
the breakpoint, the path returned from the 'fileuri'
attribute needs to be sent when the breakpoint is acted up
(created, removed).
code that is looked up via the 'source' command uses
overridden the 'getPath' method in the DBGPSourceModule
class to return the path from the stack frame and that
allows breakpoints to be successfully set, but they do not
appear because there is no IResource object available to
set the marker on. the workspace root should be able to
work as a stand in for the resource. i'm fairly certain
the mapping issue can also be solved using markers.
when the source is looked up using the
RemoteScriptSourceLookupDirector, right before the IFile
object is returned, a marker can be created that can be
used to store the path to the file on the remote host.
then in BreakpointUtils.getBreakpointResourceLocation, if
the IResource object isn't null, it can be checked for the
remote path marker, and if it exists, return that path
instead of the local object's resource.
the current roadblock i'm hitting comes in the
ScriptLineBreapoint class. both the getResourceName() and
getResourceURI() methods return the resource represented
by the breakpoint marker when it is not equal to the
workspace root. mapped resoures will never match this
case, so the local path will always be returned.
commenting out that conditional allows the remote
breakpoints to be properly set (local breakpoints still
work too), but that probably isn't the best thing to do.
do you guys think this is a workable approach? if yes,
suggestions on how to deal with the ScroptLineBreakpoint
roadblock are very welcomed. if no, i'm open to other
suggestions. i am really in need of a workable solution
because i've grown tired of the debugging hell i suffer
from on a daily basis at the day job. :)
-- -jae
_______________________________________________
dltk-dev mailing listdltk-dev@xxxxxxxxxxx <mailto:dltk-dev@xxxxxxxxxxx> ------------------------------------------------------------------------
https://dev.eclipse.org/mailman/listinfo/dltk-dev
_______________________________________________
dltk-dev mailing list
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev
_______________________________________________
dltk-dev mailing list
dltk-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/dltk-dev