Bugzilla – Full Text Bug Listing
| Summary: | Disassembly view sometimes doesn't display all source code | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| 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: | aleherb+eclipse, pawel.1.piech | ||||||||
| Version: | 7.0 | ||||||||||
| Target Milestone: | 7.0.1 | ||||||||||
| Hardware: | PC | ||||||||||
| OS: | Windows XP | ||||||||||
| Whiteboard: | |||||||||||
| Attachments: |
|
||||||||||
|
Description
Norman Yee
Created attachment 175429 [details]
Contents of disassembly view and debugger log when source code is correctly displayed in disassembly view
Created attachment 175430 [details]
Contents of disassembly view and debugger log when source code is missing in disassembly view
Does the problem occur only after enabling "Show Source"? Show Source has to be enabled to see the problem, but it doesn't always occur immediately after pressing the Show Source button. If I enable Show Source, terminate the launch, and then keep relaunching and terminating, I eventually see the missing source code problem. Created attachment 177393 [details]
change code to continue looping in case some of the retrieved mixed instructions come before startAddress
i believe i've seen this same problem using the edc windows debugger when attempting to debug the BlackFlag project in the .edc.tests resources folder. i've concentrated on dbg_stepping.cpp, but the patch appears to solve most (though not all) of the "missing source lines in mixed disassembly" problems i've encountered.
the attached patch attempts to deal with what i believe is the root cause of the problem: the algorithm in insertDisassembly() returns too soon when mixedInstructions have been returned that have "excess disassembly" that comes *before* the startAddress.
the contextual problem in edc for windows (i.e. x86 ... i.e. variable-length instructions) is that the caller to retrieveDisassembly() doesn't necessarily trust the startAddress given; it appropriately looks up the address in its LNT, and starts searching for instructions based upon an address it knows to be the start of a valid instruction. this means (fairly regularly) the start-address as passed to (and thus recognized by) retrieveInstructions() and also insertDisassembly() is decreased by a few bytes for the retrieval once getMixedInstructions() is called deeper in the provider; and so "pre-excess" instructions are collected, and the result ends up being processed by insertDisassembly().
so, the algorithm in insertDisassembly() recognizes the address of the first instruction in the mixedInstructions it gets from the content provider as being one that's already been retrieved ... and the problem is that it then immediately exits the function, with a false return value, upon which the caller acts by attempting to retrieve the same code, only as non-mixed assembly ... and this is what gets inserted in the debugger document for us to view.
the "continue" in the patch allows for looping back to the top to get the next instructions and mixedInstructions to be processed.
normally, this eventually leads to the third or fourth instruction being one that hasn't been inserted, yet, and then things proceed normally. and thus the "pre-excess" gets ignored, but doesn't abort the processing before good new mixed-disassembly can be inserted.
this should be safe for the "post-excess" case, because the conditional check "address.compareTo(endAddress)" prior to the changed code to "continue" deals with the end case, and properly returns from the function with the return value of interest.
norman, is it possible for you to apply the attached patch and see if it also solves the problem you've seen on your platform/target? this patch doesn't solve *every* case (i have a much more extensive patch that involves API changes for the other edge cases i've run into), but hopefully it will ameliorate the problem you are seeing.
anton/ken, can you review and commit if appropriate? i'll discuss my other more extensive patch in a separate ecl.bz entry once it's ready.
I see your point. This definitely makes sense. Committed to HEAD and cdt_7_0. Thanks for looking into it. *** cdt cvs genie on behalf of aleherbau *** Bug 321162 - Disassembly view sometimes doesn't display all source code Patch from Kirk Beitz (Nokia) [*] DisassemblyBackendDsf.java 1.8.2.3 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/DisassemblyBackendDsf.java?root=Tools_Project&r1=1.8.2.2&r2=1.8.2.3 [*] DisassemblyBackendDsf.java 1.11 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/DisassemblyBackendDsf.java?root=Tools_Project&r1=1.10&r2=1.11 (In reply to comment #5) > norman, is it possible for you to apply the attached patch and see if it also > solves the problem you've seen on your platform/target? this patch doesn't > solve *every* case (i have a much more extensive patch that involves API > changes for the other edge cases i've run into), but hopefully it will > ameliorate the problem you are seeing. Kirk, I grabbed the last CDT build with your patch in it and it's much better. I see all the source code but sometimes the view is missing a few disassembly instructions when I keep toggling the Show Source button. I'll enter a bug for the missing disassembly. Thank you very much for the patch! |