Community
Participate
Working Groups
Straightforward mapping on top of MI commands, plus caching and coalesing. Effort Estimate: 3, 2
Created attachment 90945 [details] First attempt at teh Disassembly service Hi, Here's a first hot at the DSF disassembly service. It isn't much more than a cosmetic re-factoring of the corresponding CDI feature but it has this "DSF feel" :-) Here's a summary of the patch: [1] I created the following DSF interfaces: - IDisassembly (for the service) - IInstruction (for assembly instructions) - IMixedInstruction (for the mixed source + assembly instructions) [2] At the MI service layer, I created the following: - MIDisassembly which implements IDisassembly - MIInstruction which implements IInstruction - MIMixedInstruction which implements IMixedInstruction [3] At the MI command layer: - MIDataDisassemble - MIDataDisassembleInfo [4] I created an IDisassemblyDMContext (extending IDMContext) and made GdbControlDMC implement it. [5] I updated the launch and shutdown sequences. [6] Finally, I created a JUnit test suite for the service (not complete but good enough). Will finalize it once we have agreed on IDisassembly. The service is not hooked to the UI since we haven't come to a decision yet on how to do it. This is really a first draft meant to be a basis for discussion, in particular for the following elements: - Pertinence of IInstruction and IMixedInstruction at the DSF layer - IDisassemblyDMContext and GdbControlDMC - Should MIDisassembly retrieve the actual source code lines (using the source lookup service) or should it leave it to the higher level entity that will tie the service to the UI? - Caching and coalescing: what is there to do? Best Regards, /fc
(In reply to comment #1) That was some quick work :-) On a quick glance the APIs look fine to me. As far as your open issues: > - Pertinence of IInstruction and IMixedInstruction at the DSF layer I think it makes sense to include these in the dsf.debug plugin. > - IDisassemblyDMContext and GdbControlDMC I can't think of a case where the disassembly context would be different than the memory context. To avoid direct references to IMemoryDMContext, the IDisassembly interface could just accept a generic IDMContext. > - Should MIDisassembly retrieve the actual source code lines (using the source > lookup service) or should it leave it to the higher level entity that will tie > the service to the UI? I don't think so. There is more flexibility for peforming source lookup at the UI level. > - Caching and coalescing: what is there to do? Hmm. CommandCache is still broken with respect to coalescing, but it seems like the correct mechanism. For now, it could be enough to just cache the MI commands, even if there will be overlap in them.
Committed the patch. /fc
(In reply to comment #2) > > - IDisassemblyDMContext and GdbControlDMC > I can't think of a case where the disassembly context would be different than > the memory context. To avoid direct references to IMemoryDMContext, the > IDisassembly interface could just accept a generic IDMContext. Then, I would rather keep it as is. It doesn't hurt and it makes the API look "cleaner" (IMHO). > > - Should MIDisassembly retrieve the actual source code lines (using the source > > lookup service) or should it leave it to the higher level entity that will tie > > the service to the UI? > I don't think so. There is more flexibility for peforming source lookup at the > UI level. I agree. I just raised the issue in case we consider changing IMixedInstruction to hold the actual source line instead of a reference to it (file + line). > > - Caching and coalescing: what is there to do? > Hmm. CommandCache is still broken with respect to coalescing, but it seems > like the correct mechanism. For now, it could be enough to just cache the MI > commands, even if there will be overlap in them. I think I will leave this one on the back burner. I have a few ideas about caching but I wouldn't want to start another psycho-drama like we had with Memory vs. Expression. And it is probably not worth the trouble. Really. BR, /fc
Excellent. We may yet get to use the new Disassembly view being created by Mikhail. He indicated that he will commit it to CDT soon. (In reply to comment #4) > > > - Caching and coalescing: what is there to do? > > Hmm. CommandCache is still broken with respect to coalescing, but it seems > > like the correct mechanism. For now, it could be enough to just cache the MI > > commands, even if there will be overlap in them. > > I think I will leave this one on the back burner. I have a few ideas about > caching but I wouldn't want to start another psycho-drama like we had with > Memory vs. Expression. And it is probably not worth the trouble. Really. I had an interesting discussion with Eugene Tassarov who is working on the TCF framework now in the Target Managment project. He is creating a DSF-TCF debugger integration and he's doing a lot of experimenting with different caching techniques. I hope that we will be able to re-use his work and make it part of the generic DSF classes and that should help with use cases such as this. Though I don't think it'll happen in time for Ganymede/1.0.
Is there anything else to be done for this bug (given that the disassembly view works, I would guess not :-)) If it's done, please mark it fixed.
Done.
reopen for review
Marking back as fixed
Reviewed.
Closing out 1.0 bugs.
