Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 363927

Summary:

Cannot display instruction code bytes in disassembly view

Product:

[Tools] TCF

Reporter:

Scott Tepavich <scott.tepavich>

Component:

Debug

Assignee:

Project Inbox <tcf.debug-inbox>

Status:

RESOLVED FIXED

QA Contact:

Eugene Tarassov <eugene>

Severity:

enhancement

Priority:

CC:

cdtdoug

Version:

unspecified

Target Milestone:

1.1

Hardware:

OS:

Windows XP

Whiteboard:

Attachments:

Description	Flags
Proposed patch	eugene: iplog-

Description Scott Tepavich

2011-11-16 10:40:43 EST

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.

Comment 1 Scott Tepavich

2011-11-16 10:42:19 EST

Created attachment 207096 [details]
Proposed patch

Comment 2 Eugene Tarassov

2011-11-16 14:23:01 EST

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.

Comment 3 Scott Tepavich

2011-11-16 14:33:19 EST

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.

Comment 4 Eugene Tarassov

2012-09-04 21:29:15 EDT

This is fixed by an independent commit.