[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [Dltk-dev] breakpoints for remote debugging
|
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> 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> 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
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 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
-jae
--
-jae
