Community
Participate
Working Groups
When choosing a binary somewhere on the file system, instead of part of a project, showing the source code in the disassembly fails because it cannot find the source file. I see the following: !ENTRY org.eclipse.cdt.dsf.ui 2 0 2011-05-01 21:27:20.523 !MESSAGE Unable to locate file: ../src/Consumer.cpp So, it seems that GDB returns a relative path with respect to the location of the binary in question. However, this does not seem to work for us. Surely something about the path that is being used by the disassembly code.
Reason seems to be an Exception caused by ProgramRelativePathSourceContainer trying to get a project for an empty string: Error Mon May 02 11:22:40 CEST 2011 Problems occurred when invoking code from plug-in: "org.eclipse.debug.core". java.lang.IllegalArgumentException: Path for project must have only one segment. at org.eclipse.core.runtime.Assert.isLegal(Assert.java:63) at org.eclipse.core.internal.resources.WorkspaceRoot.getProject(WorkspaceRoot.java:184) at org.eclipse.cdt.internal.core.model.CModel.getCProject(CModel.java:63) at org.eclipse.cdt.debug.core.sourcelookup.ProgramRelativePathSourceContainer.getProgramLocation(ProgramRelativePathSourceContainer.java:148) at org.eclipse.cdt.debug.core.sourcelookup.ProgramRelativePathSourceContainer.findSourceElements(ProgramRelativePathSourceContainer.java:96) at org.eclipse.debug.core.sourcelookup.containers.CompositeSourceContainer.findSourceElements(CompositeSourceContainer.java:79) at org.eclipse.debug.core.sourcelookup.containers.CompositeSourceContainer.findSourceElements(CompositeSourceContainer.java:46) at org.eclipse.debug.core.sourcelookup.AbstractSourceLookupParticipant.findSourceElements(AbstractSourceLookupParticipant.java:67) at org.eclipse.cdt.debug.internal.core.sourcelookup.CSourceLookupParticipant.findSourceElements(CSourceLookupParticipant.java:117) at org.eclipse.debug.core.sourcelookup.AbstractSourceLookupDirector$SourceLookupQuery.run(AbstractSourceLookupDirector.java:141) at org.eclipse.core.runtime.SafeRunner.run(SafeRunner.java:42) at org.eclipse.debug.core.sourcelookup.AbstractSourceLookupDirector.findSourceElements(AbstractSourceLookupDirector.java:742) at org.eclipse.cdt.dsf.mi.service.CSourceLookup$3.run(CSourceLookup.java:196) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:54) BTW, project-less debugging does not work natively on Windows, because the binary is not recognized as an executable by the default binary parser (which is always the ElfParser).
(In reply to comment #1) > Reason seems to be an Exception caused by ProgramRelativePathSourceContainer > trying to get a project for an empty string: It seems we missed the case of a project being an empty string in the fix to Bug 304433. > BTW, project-less debugging does not work natively on Windows, because the > binary is not recognized as an executable by the default binary parser (which > is always the ElfParser). I've opened Bug 344470 about this.
Created attachment 194500 [details] Fix Fix which checks if a project is an empty string. Committed to HEAD.
Thanks for the help Toni. Can you review the one line fix?
A similar problem happens for multi-process and I've opened Bug 344471 about it. I am looking into it.
*** cdt cvs genie on behalf of mkhouzam *** Bug 344408: Cannot show mixed-mode disassembly when doing project-less debug [*] ProgramRelativePathSourceContainer.java 1.5 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.debug.core/src/org/eclipse/cdt/debug/core/sourcelookup/ProgramRelativePathSourceContainer.java?root=Tools_Project&r1=1.4&r2=1.5
