| Summary: | DSF disassembly view doesn't display mixed instructions from multiple files | ||||||||
|---|---|---|---|---|---|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Norman Yee <normankyee> | ||||||
| Component: | cdt-debug-dsf | Assignee: | Anton Leherbauer <aleherb+eclipse> | ||||||
| Status: | RESOLVED FIXED | QA Contact: | Pawel Piech <pawel.1.piech> | ||||||
| Severity: | normal | ||||||||
| Priority: | P3 | CC: | glen.anderson, pawel.1.piech | ||||||
| Version: | 7.0 | ||||||||
| Target Milestone: | 7.0 | ||||||||
| Hardware: | PC | ||||||||
| OS: | Windows XP | ||||||||
| Whiteboard: | |||||||||
| Attachments: |
|
||||||||
Created attachment 165910 [details]
Proposed fix for this bug.
This patch changes the disassembly view so that it retrieves the mixed instructions by address range first instead of by file and line range.
Created attachment 166299 [details]
Alternative fix
Thanks for the patch.
Please give this very simple fix a try. It changes the behavior for both DSF and CDI at the same time and it makes the disassembly never issue requests based on file / line range.
Yes, your alternative fix works. Thanks for looking into this. Fixed in HEAD. This bug is now back in Eclipse 3.6 so I am re-opening this bug. I downloaded the latest CDT sources and it looks like the disassembly view code got re-organized(e.g. DisassemblyPart.java is gone) so maybe the fix got lost somewhere in the changes? Sorry my mistake. It's not a new bug in Helios. After some more investigating, I noticed that the bug was in 3.5M7 also but it was not always reproducible under 3.5M7 or 3.6. I can eventually reproduce the bug if I keep updating disassembly view by a) terminating the session and relaunching it, or b) toggling the "Show Source" button in the Disassembly view. When the Show Source button is enabled, I'm sometimes missing source code from the disassembly view. If I toggle the "Show Source" button enough times, I'll see all the source code I'm expecting. (In reply to comment #6) > After some more investigating, I noticed that the bug was in 3.5M7 also but it > was not always reproducible under 3.5M7 or 3.6. I can eventually reproduce the > bug if I keep updating disassembly view by a) terminating the session and > relaunching it, or b) toggling the "Show Source" button in the Disassembly > view. Note that CDT has its own versioning and I won't look at bugs which occur in old milestone builds pre 7.0. Please file a new bug with reproducible test case and attach the gdb/mi log. *** cdt cvs genie on behalf of aleherbau *** Bug 310443 - DSF Disassembly part cannot locate external source files Bug 310171 - DSF disassembly view doesn't display mixed instructions from multiple files [*] DisassemblyPart.java 1.30 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt/dsf/org.eclipse.cdt.dsf.ui/src/org/eclipse/cdt/dsf/debug/internal/ui/disassembly/DisassemblyPart.java?root=Tools_Project&r1=1.29&r2=1.30 [*] DisassemblyBackendCdi.java 1.10 http://dev.eclipse.org/viewcvs/index.cgi/org.eclipse.cdt-debug/org.eclipse.cdt.debug.ui/src/org/eclipse/cdt/debug/internal/ui/disassembly/dsf/DisassemblyBackendCdi.java?root=Tools_Project&r1=1.9&r2=1.10 |
Build Identifier: I20100312-1448 The DSF disassembly view can display disassembly interspersed with the source code that corresponds to the disassembly. If the source code is from multiple files, the disassembly view will only display the mixed instructions for one file, the one in the current stack frame, and the mixed instructions for the other files are missing. Consider this example: I have a main.cpp that contains: #include <stdio.h> #include "foobar.h" int main(void) { int x = 0; x = inc(x); printf("x = %d\n", x); return 0; } and foobar.h contains: inline int inc(int a) { return a + 1; } If I'm viewing the disassembly for main(), I only see the mixed instructions for main() but the mixed instructions for inc() are not shown because the source code is located in a different source file, foobar.h. Looking at the source code for the DSF disassembly view, I think the problem is that it calls the DSF disassembly service's getMixedInstructions(IDisassemblyDMContext, String filename, int linenum, int lines, DataRequestMonitor<IMixedInstruction[]>) first. If that fails, it calls getMixedInstructions(IDisassemblyDMContext, BigInteger startAddress, BigInteger endAddress, DataRequestMonitor<IMixedInstruction[]>), which can return mixed instructions from multiple source files. I think it should be changed so that it skips the first call and just uses getMixedInstructions(IDisassemblyDMContext, BigInteger startAddress, BigInteger endAddress, DataRequestMonitor<IMixedInstruction[]>). I am writing a custom DSF debugger plugin and I can work around the problem by returning a failure code in my implementation of the DSF disassembly service's getMixedInstructions(IDisassemblyDMContext, String filename, int linenum, int lines, DataRequestMonitor<IMixedInstruction[]>). This forces the disassembly view to call getMixedInstructions(IDisassemblyDMContext, BigInteger startAddress, BigInteger endAddress, DataRequestMonitor<IMixedInstruction[]>) and then I see the correct mixed instructions in the disassembly view. I would prefer that this problem be fixed in the disassembly view. Reproducible: Always