| GCov integration plug-in only accepts executable files from loaded project folders [message #999992] |
Sun, 13 January 2013 18:00  |
 Tamas Kleiber
Messages: 20
Registered: December 2010 |
Junior Member |
|
|
Hello,
I have some problems opening a Win32/PE executable with the gcov integration plug-in if the executable can be found in a folder which is not part of the CDT project itself or if the executable is linked into the project using linked resources from whatever local or arbitrary place.
Example:
eclipse workspace: c:/workspace/
CDT project home: o:/test_project/
executable location: c:/output_files/unittest.exe
In this particular setup, if the executable is selected using "File System..." gcov plug-in throws "c:/output_files/unittest.exe is not a valid binary file." Error.
If executable location is: o:/test_project/unittest.exe, everything is fine, the executable is opened without any problems.
If an arbitrary folder is linked into CDT's project explorer view as a linked resource the error is thrown again even if executable is opened with the "Workspace..." button.
The following code line fails in OpenGCDialog.java inside member validateBinary():
IBinaryObject binary = STSymbolManager.sharedInstance.getBinaryObject(new Path(binValue));
I traced through the code and in STSymbolManager.sharedInstance.getBinaryObject(), the first code line fails:
IFile c = ResourcesPlugin.getWorkspace().getRoot().getFileForLocation(path);
Variable c becomes null. The path input parameter is a valid path outside of the CDT project home: "c:/output_files/unittest.exe"
The documentation of .getFileForLocation() states the followings:
Quote:
Returns a handle to the file which is mapped to the given path in the local file system, or null if none. The path should be absolute; a relative path will be treated as absolute. The path segments need not be valid names. The resulting file may not currently exist.
This method returns null when the given file system location is not under the location of any existing project in the workspace.
The result will also omit resources that are explicitly excluded from the workspace according to existing resource filters.
Warning: This method ignores linked resources and their children. Since linked resources may overlap other resources, a unique mapping from a file system location to a single resource is not guaranteed. To find all resources for a given location, including linked resources, use the method findFilesForLocation.
This means that the currently used interface in STSymbolManager.sharedInstance.getBinaryObject() can only open executables which are directly stored under a loaded project's home folder. In my opinion this is a very big limitation and for example in my case I cannot resolve it without violation of workplace policies.
Would it be possible to update method getBinaryObject() in STSymbolManager() class to support also arbitrary locations and not only ones from the project folder itself without linked resources?
|
|
|
|
|
|
|
|
|
|
Powered by
FUDForum. Page generated in 0.02529 seconds
Search
Help
Register
Login
Home
