Community
Participate
Working Groups
The debugger may display source files outside the scope of the launch's source containers because the back-end is able to provide the full path to the file. However when you set a breakpoint in one of these files the break will be ignored because the source locator is unable to locate it even though the full path is available. This problem was first identified in bug 91808 and a subsequent workaround in CSourceLookupParticipant.java was added that enables display of these files. A more comprehensive way to address this is to add a source container that knows how to “find” files specified by their full absolute path. Adding a AbsolutePathSourceContainer removes the need for the workaround, fixes this bug where breakpoints can not be set in these files, and should cover additional cases in the future. Patch to follow...
Created attachment 51473 [details] Icon for contianer In Wind River product, we called this container the "Debugger Path in Filesystem" and we add it by default to every launch using the path computer. I attached the container icon.
(In reply to comment #0) > A more comprehensive way to address this is to add a source container that > knows how to “find” files specified by their full absolute path. Adding a > AbsolutePathSourceContainer removes the need for the workaround, fixes this bug > where breakpoints can not be set in these files, and should cover additional > cases in the future. How is this different from org.eclipse.debug.core.sourcelookup.containers.DirectorySourceContainer, which CDT already uses when you add a "File System Directory" to the source lookup path in the Source tab of the launch config dialog?
DirectorySourceContainer will take the path that comes from the debugger and append it to the directory path that its configured for. I suppose you could create a directory SC for the root directory, but it won't work on windows because of the drive letter thing. Also the directory SC will only return the LocalFileStorage object as a result, which is not so desirable if the file also referenced in the workspace. I'm not sure if Ken had this in mind, but our version of this container first searched for the file in workspace, if it wasn't there, only then it would return the LocalFileStorage version. For reference this is what our find elements method looks like. Note that the searching under canonical path was necessary in some cases when the pre-processor changed the case of the filenames that ended up in the symbol file. public Object[] findSourceElements(String name) throws CoreException { List retVal = new ArrayList(); File searchFile = new File(name); if (searchFile.exists() && searchFile.isFile()) { // Try to find the file in the workspace IFile[] files = ResourcesPlugin.getWorkspace().getRoot(). findFilesForLocation( new Path(searchFile.getAbsolutePath()) ); for (int i = 0; i < files.length; i++) { if (files[i].exists()) { retVal.add(files[i]); } } // Also search for files under the canonical path. This will // guarantee that the search path is in correct case if looking on // a windows system. try { files = ResourcesPlugin.getWorkspace().getRoot(). findFilesForLocation( new Path(searchFile.getCanonicalPath()) ); for (int i = 0; i < files.length; i++) { if (files[i].exists()) { retVal.add(files[i]); } } } catch (IOException e) {} // getCanonicalPath() can throw retVal.add( new LocalFileStorage(searchFile) ); } return retVal.toArray(); }
Created attachment 51502 [details] Initial, patch against CDT_31 This was my first pass at this. It needs Pawel's icon and I'll add the canonical path stuff too.
After incorporating Pawel's feedback, committed fix to HEAD and CDT_3_1.
