Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 341168

Summary: EDC Dwarf Reader shouldn't do source mapping
Product: [Tools] CDT Reporter: John Cortell <john.cortell>
Component: cdt-debug-edcAssignee: Ken Ryall <ken.ryall>
Status: RESOLVED WONTFIX QA Contact: Ken Ryall <ken.ryall>
Severity: normal    
Priority: P3 CC: cdtdoug
Version: 8.0Flags: ken.ryall: review+
Target Milestone: 8.0   
Hardware: PC   
OS: Windows XP   
Whiteboard:
Attachments:
Description Flags
fix
john.cortell: iplog-
Manual tests I used to validate fix none

Description John Cortell CLA 2011-03-28 16:47:31 EDT 
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
Comment 1 John Cortell CLA 2011-04-14 16:40:59 EDT 
Created attachment 193295 [details]
fix
Comment 2 John Cortell CLA 2011-04-14 16:43:34 EDT 
Created attachment 193296 [details]
Manual tests I used to validate fix
Comment 4 John Cortell CLA 2011-04-15 08:40:22 EDT 
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.
Comment 5 Ken Ryall CLA 2011-04-26 00:00:26 EDT 
Looks good to me. Sorry for the delay, I had forgotten to mark it off in bugzilla.
Comment 6 Jonah Graham CLA 2019-12-30 18:39:45 EST 
(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/