Community
Participate
Working Groups
Build Identifier: 20110615-0604 When debugging in assembly mode, the CDT disassembly view cannot access instruction code bytes to display for the user. Reproducible: Always Steps to Reproduce: 1. Debug a target context in disassembly mode. 2. Attempt to display instruction code bytes for the displayed assembly code.
Created attachment 207096 [details] Proposed patch
I see some issues with the patch: 1. IDisassembly.IDisassemblyLine.getOpcode() appears to be redundant. The opcode can be retrieved with IMemory.MemoryContext.get(). It is more efficient (can retrieve all instructions at once) and backward compatible with existing agents. Even if we add getOpcode() method, the code in TCFDisassemblyBackend should be able to fall back to use of IMemory.MemoryContext.get() when connected to an older agent. 2. Compilation error: TCFDisassemblyBackend calls IDisassemblyDocument.insertDisassemblyLine() with arguments that are not compatible with latest released CDT code. Does it depend on a new API that is not released yet? 3. The new code in TCFDisassemblyBackend appears not able to handle cache misses - when TCFDataCache.validate() returns false. It seems the code ignores all consequences of a cache miss, which can cause a lot of problems. 4. The new code in TCFDisassemblyBackend accesses TCF APIs from UI thread. TCF methods cal be called only from TCF thread. The code should use TCFTask or similar classes to delegate execution to the TCF thread.
Thanks for the feedback! 1. IDisassembly.IDisassemblyLine.getOpcode() appears to be redundant. As part of the TCF Disassembly disassemble service command (as reviewed by Felix), the servicce provider already contains the memory buffer. Felix green-lighted the update to the service, but you are correct. If the underlying Disassembly service does not supply this functionality, then it should be retrieved with IMemory.MemoryContext.get(). I'll make the update. 2. Does it depend on a new API that is not released yet? Yes, this is only intended to be used with CDT 9. 3. The new code in TCFDisassemblyBackend appears not able to handle cache misses - when TCFDataCache.validate() returns false. It seems the code ignores all consequences of a cache miss, which can cause a lot of problems. I'll update the cache misses. 4. The new code in TCFDisassemblyBackend accesses TCF APIs from UI thread. TCF methods cal be called only from TCF thread. The code should use TCFTask or similar classes to delegate execution to the TCF thread. Okay.
This is fixed by an independent commit.
