Bugzilla – Full Text Bug Listing
| Summary: | Disassembly view sometimes doesn't display all assembly instructions in Show Source mode | ||
|---|---|---|---|
| Product: | [Tools] CDT | Reporter: | Norman Yee <normankyee> |
| Component: | cdt-debug-dsf | Assignee: | Project Inbox <cdt-debug-dsf-inbox> |
| Status: | CLOSED INVALID | QA Contact: | Pawel Piech <pawel.1.piech> |
| Severity: | normal | ||
| Priority: | P3 | CC: | aleherb+eclipse, pawel.1.piech |
| Version: | 7.0 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
| Attachments: | |||
|
Description
Norman Yee
Created attachment 177613 [details]
Contents of disassembly view and debugger log when assembly code is correctly displayed in disassembly view
Created attachment 177614 [details]
Contents of disassembly view and debugger log when assembly code is missing in disassembly view
Note that the assembly instructions at addresses ffa01416 to ffa01420 are missing.
I assume those logs were made with the patch for bug 321162 applied? What seems strange is that the first request for disassembly is for a range of 1 byte: Start Address: 0xffa01406 End Address: 0xffa01407 Looking at the code I would assume this is not possible, because retrieveDisassembly makes sure to retrieve a minimum of 32 bytes. Also, the next query for mixed instructions starts again from 0xffa01406. Actually, this should not happen. If the first attempt failed, it should repeat the query for non-mixed instructions. Could you enable disassembly tracing and attach the output when the problem occurs? If you are launch from a workspace, enable the tracing in the launch configuration (org.eclipse.cdt.dsf.ui/debug/disassembly), or put the line org.eclipse.cdt.dsf.ui/debug/disassembly=true into a file ".options" in your eclipse home directory and start Eclipse with -debug. Created attachment 178435 [details]
Contents of disassembly view, debugger log, and trace output when assembly code is missing in disassembly view
(In reply to comment #3) > I assume those logs were made with the patch for bug 321162 applied? Yes. You had already checked in your changes so I just installed the latest nightly CDT build. > What seems strange is that the first request for disassembly is for a range of > 1 byte: > > Start Address: 0xffa01406 End Address: 0xffa01407 > > Looking at the code I would assume this is not possible, because > retrieveDisassembly makes sure to retrieve a minimum of 32 bytes. Sorry, I should have mentioned that the first call to getMixedInstructions() is not coming from the disassembly view but from my debugger plugin, which is using getMixedInstructions() to check if the processor is halted at an address with source code. > Also, the next query for mixed instructions starts again from 0xffa01406. > Actually, this should not happen. If the first attempt failed, it should > repeat the query for non-mixed instructions. > > Could you enable disassembly tracing and attach the output when the problem > occurs? > If you are launch from a workspace, enable the tracing in the launch > configuration (org.eclipse.cdt.dsf.ui/debug/disassembly), or put the line > org.eclipse.cdt.dsf.ui/debug/disassembly=true > into a file ".options" in your eclipse home directory and start Eclipse with > -debug. Ok, I've attached a new log file with the trace output. From the trace output it looks like some IInstruction objects return an empty string or null for IInstruction.getInstruction(). Can this be true? Yup, you're right. It turns out that an internal object in my debugger plugin was being destructed early so IInstruction.getInstruction() could have been returning null or an empty string. Thanks for your help! This is not a bug so I'm closing it. |