Community
Participate
Working Groups
In bug 297778, I removed the logic from the dwarf reader that massaged the file specification in the executable to something suitable on the local machine. As I stated in that bug report, this is not what a symbolics reader should be doing. It should stay true to the information in the binary and let contributed Source Lookup Paths do the mapping, as that's what they're designed to do. It looks like the mapping functionality made its way back via some redesign/refactoring that put the logic in an EDC dwarf reader. See DwarfFileHelper.fixUpPath(String) and DwarfFileHelper.normalizePath(String, String) Again, I believe putting this sort of mapping logic in the dwarf reader is misguided. If I have a binary built on linux in /some/dir and I import the file into the Executables view on Windows, it's very misleading for that view to tell me the executable was built in c:\some\dir
Created attachment 193295 [details] fix
Created attachment 193296 [details] Manual tests I used to validate fix
*** cdt cvs genie on behalf of jcortell *** Bug 341168 - EDC Dwarf Reader shouldn't do source mapping [*] SourceFilesViewer.java 1.9 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.debug.ui/src/org/eclipse/cdt/debug/internal/ui/views/executables/SourceFilesViewer.java?root=Tools_Project&r1=1.8&r2=1.9 [*] Util.java 1.6 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.core/utils/org/eclipse/cdt/internal/core/Util.java?root=Tools_Project&r1=1.5&r2=1.6 [*] DwarfFileHelper.java 1.2 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/edc/org.eclipse.cdt.debug.edc/src/org/eclipse/cdt/debug/edc/internal/symbols/dwarf/DwarfFileHelper.java?root=Tools_Project&r1=1.1&r2=1.2 [*] Executable.java 1.16 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/all/org.eclipse.cdt.debug.core/src/org/eclipse/cdt/debug/core/executables/Executable.java?root=Tools_Project&r1=1.15&r2=1.16
Note that this fix contains changes for the Executables view/manager as well. We need to avoid converting a string file path to a java.io.File if the file isn't absolute, since File will make assumptions about where the file lives locally. For example, on Windows, File("/some/foo.c") will end up creating a representation for c:\some\file.txt, if the eclipse process working directory is on the c: drive. Consequently, we end up misleading the user into thinking the the dwarf info contains c:\some\foo.c. If a source file specification in the dwarf info ends up being a non-absolute path after being run through the source lookup paths, then it should remain ambiguous. Features should not try to make assumptions or best-guess attempts at giving the file a local representation. For one, any such assumption-making would be decentralized and thus could lead to inconsistent behavior from one feature to another (e.g., the editor opens the file here, but the breakpoints code thinks it's there). 'Source lookup paths' is the common mechanism for finding/remapping files locally, and only that mechanism should result in a non-absolute path becoming a local absolute one.
Looks good to me. Sorry for the delay, I had forgotten to mark it off in bugzilla.
(this is part of a batch change) The Eclipse CDT EDC (https://wiki.eclipse.org/CDT/cdt-debug-edc) is now obsolete and has not had any active development since 2011. Therefore the still open bugs are being marked as wontfix. The git repo for the project still exists for posterity at https://git.eclipse.org/c/cdt/org.eclipse.cdt.edc.git/
