Community
Participate
Working Groups
An error dialog with "Operation failed" (an no further useful info) is displayed whenever you do "Load Symbols for All" in the Modules view during a debug session. In fact, no error has really occurred. Just faulty handling in CModule.loadSymbolsFromFile().
Fixed on HEAD (CDT 5.X) /cvsroot/tools/org.eclipse.cdt-debug/org.eclipse.cdt.debug.core/src/org/eclipse/cdt/debug/internal/core/model/CModule.java rev: 1.9
should we fix it on 5.0.1 too? Can you attach a patch please?
Applied to cdt_5_0 /cvsroot/tools/org.eclipse.cdt-debug/org.eclipse.cdt.debug.core/src/org/eclipse/cdt/debug/internal/core/model/CModule.java rev: 1.8.8.1
When path to library name not match file name - it is an error - debugger does not support loading such libraries - we should fix error message not hide diagnostics.
Something like this: (+ internationalization) private void loadSymbolsFromFile( IPath path ) throws DebugException { if ( path == null || path.isEmpty() ) { requestFailed( CoreModelMessages.getString( "CModule.2" ), null ); //$NON-NLS-1$ } else if (fCDIObject instanceof ICDISharedLibrary) { if (path.equals(getSymbolsFileName())) { try { ((ICDISharedLibrary) fCDIObject).loadSymbols(); } catch (CDIException e) { targetRequestFailed(e.getMessage(), null); } } else { targetRequestFailed("Cannot load library from file: "+path+". Library name must match file name.", null); } } else { targetRequestFailed("Not a library object", null); } }
- remove last else clause from my snippet - I guess that was causing a problem - if it is not a library just skip it...
First of all, if CDT does not support the user specifying a symbolics file that doesn't share the same name as the binary, then it should complain when the user makes the assignment (should flat out not accept it). But more importantly, why is it an error at all? The ability to store debug information outside the generataed binary (typically in a file that accompanies the executable) is nothing new. John
gdb does not support it - that is only problem. And because of it we should tell user that it would not work. Technically this code should be gdb independent and we should have an interface ICDISharedLibrary.loadSymbols(File file) If we not ready to re-write it now I suggest we just change your fix a bit to return diagnostics when path does not match (it will still work better because now it chokes on binary in modules view).
Created attachment 107363 [details] patch
Can you clarify what you mean by "now it chokes on binary in modules view"?
If you run action Load all before your fix - it will show an error, the reason it shows it because Modules view contains object which is not shared library - it is binary (I think). After your fix it would not show any errors, including when user selected wrong file. If you apply my fix - load all would work and it will still shown an error if file paths are mismatching
I looked at it again - it is all so ugly that it does not matter, this code that added would not be executed anyway, so we can leave it as it until we rewrite it properly
(In reply to comment #12) > I looked at it again - it is all so ugly that it does not matter, this code > that added would not be executed anyway, so we can leave it as it until we > rewrite it properly > Yes; it's all quite a bit of nonsense. We allow the user to enter a symbolics file that differs from the binary, but then if he does, we don't honor it and produce an error when he tries to load the symbolics.
Well it is same code (this function) that CDT uses to validate that path is ok when user sets it in a first place. But I don't see how it can match: library name is basename - and path to a file - is full path.
