Community
Participate
Working Groups
Build Identifier: I20100608-0911 The disassembly view sometimes doesn't display all the source code it's supposed to when "Show Source" is enabled. This might be related to Bug 310171 that I previously entered. I can reproduce the problem by forcing the disassembly to update: a) if I keep terminating the launch and then relaunching it or b) if I keep toggling the "Show Source" button. Sometimes the disassembly view is missing a few source lines, sometimes it's missing all source lines. I am using a custom DSF debugger plugin that is not gdb/MI based. I'll attach the log generated by my debugger to show the DSF disassembly calls. Reproducible: Sometimes Steps to Reproduce: 1. launch the debug configuration 2. open the disassembly view 3. enable "Show Source" 4. if the disassembly view is not missing any source code, keep terminating the launch and relaunching it until you see the bug Another way to reproduce the bug: 1. enable "Show Source" 2. if you don't see the bug, disable "Show Source" and keep toggling "Show Source" until you see bug
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!
