Community
Participate
Working Groups
With GDB 7.3, the command -data-disassemble can also return the list of opcodes matching the disassembly. It would be nice to have an option to show those opcodes in the disassembly view.
Bug 357073 will be adding the MIDataDisassemble changes to support this.
This functionality was part of the original WR disassembly view as donated to eclipse -- which prompted us to add support to GDB ;) I suspect fixing this should be straightforward as it certainly (used to) work in our fork of the disassembly view.
(In reply to comment #2) > This functionality was part of the original WR disassembly view as donated to > eclipse -- which prompted us to add support to GDB ;) Nice! > I suspect fixing this should be straightforward as it certainly (used to) work > in our fork of the disassembly view. I gather it is something Broadcom is planning on doing, and was started with Bug 357073. Looking forward to it :-)
Adding bug 357440 as a dependency. The ruler column is now available. I hope it suits your needs!
After investigating why the opcodes display doesn't work, I found this feature request and saw that the low-level part, querying the opcodes from GDB, is already finished (Bug 357073) and the high-level part, the opcode column in the view and related preferences, as well (Bug 357440), but it seems that nobody found the time to implement the tiny middle part connecting the two ends: http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/tree/dsf/org.eclipse.cdt.dsf/src/org/eclipse/cdt/dsf/debug/service/IInstruction.java needs a small addition to store raw opcode bytes http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/tree/dsf-gdb/org.eclipse.cdt.dsf.gdb/src/org/eclipse/cdt/dsf/mi/service/command/output/MIInstruction.java needs a small addition to parse the opcode bytes in the GDB response http://git.eclipse.org/c/cdt/org.eclipse.cdt.git/tree/dsf/org.eclipse.cdt.dsf.ui/src/org/eclipse/cdt/dsf/debug/internal/ui/disassembly/DisassemblyBackendDsf.java needs a small addition to retrieve the opcode bytes and put them in the disassembly Does anyone feel like doing that?
(In reply to Axel Siebert from comment #5) > Does anyone feel like doing that? It seems you have made a lot of progress investing this already. I'm sure this would get reviewed if you pushed a patch to Gerrit and it would be a nice addition ;) http://wiki.eclipse.org/Getting_started_with_CDT_development http://wiki.eclipse.org/CDT/git#Using_Gerrit_for_CDT
In reply to Axel Siebert from comment #5) > Does anyone feel like doing that? (In reply to Marc-Andre Laperle from comment #6) > (In reply to Axel Siebert from comment #5) > > Does anyone feel like doing that? > > It seems you have made a lot of progress investing this already. I'm sure > this would get reviewed if you pushed a patch to Gerrit and it would be a > nice addition ;) > > http://wiki.eclipse.org/Getting_started_with_CDT_development > http://wiki.eclipse.org/CDT/git#Using_Gerrit_for_CDT If Axel does not wish to do this then we (Renesas) have an implementation we would be happy to contribute, we were planning on doing this but are still in the process of sorting out a contribution agreement.
Pushed to Gerrit for review (https://git.eclipse.org/r/22972), along with some explanatory comments/queries.
(In reply to William Riley from comment #8) > Pushed to Gerrit for review (https://git.eclipse.org/r/22972), along with > some explanatory comments/queries. Thanks William. What is the current situation with your contribution agreement?
(In reply to Marc Khouzam from comment #9) > (In reply to William Riley from comment #8) > > Pushed to Gerrit for review (https://git.eclipse.org/r/22972), along with > > some explanatory comments/queries. > > Thanks William. > > What is the current situation with your contribution agreement? I have signed an individual Contributor License Agreement, with approval. My understanding is that there is a company equivalent of this which we are in the process of signing (I'm not dealing with this directly). If the individual CLA is not sufficient I will chase the company agreement up more urgently.
The original posted patch, even without empty lines is more than 250 lines, so I will have to open a CQ to approve it.
I've filed the CQ: https://dev.eclipse.org/ipzilla/show_bug.cgi?id=8139 (I believe only committers can login to ipzilla)
(In reply to Marc Khouzam from comment #12) > I've filed the CQ: > https://dev.eclipse.org/ipzilla/show_bug.cgi?id=8139 > (I believe only committers can login to ipzilla) CQ has been approved. I'll commit soon.
Committed to master. Thanks William! Could you add an entry to the New and Noteworthy: http://wiki.eclipse.org/CDT/User/NewIn84
(In reply to Marc Khouzam from comment #14) > Committed to master. > Thanks William! > > Could you add an entry to the New and Noteworthy: > http://wiki.eclipse.org/CDT/User/NewIn84 Thanks for reviewing this. Will do.
This patch does not work properly for architectures that have variable-size instructions (such as ARM). The opcodes are always displayed as 32-bit values, even though (in Thumb mode) many instruction are only 16-bit. The data-disassemble command does the correct thing (in returning an opcode as 16 or 32 bits, so it is just the display that is getting it wrong. For example, here is the data-disassemble for a bit of code (reformatted to highlight): {address="0x1400028a",func-name="c_entry",offset="54", opcodes="a3 fb 00 12",inst="umull\tr1, r2, r3, r0"}, {address="0x1400028e",func-name="c_entry",offset="58", opcodes="92 09",inst="lsrs\tr2, r2, #6"} notice the first instruction is 32-bits and the 2nd is 16 bits. In the disassembly view, the opcodes display as (address) 0xa3fb0012 ... (address) 0x00009209 ...
The ruler column (added in https://bugs.eclipse.org/bugs/show_bug.cgi?id=357440) pads all opcodes to the same length on display. I did briefly look into using the number of opcode bytes returned as the instruction size. However GDB does not appear to return opcodes for fixed length instructions sets correctly, meaning the number of bytes returned cannot be used as instruction size. e.g. On an instruction set with a 4 byte fixed size GDB is returning only returns 2 bytes (opcodes="00 00") for some instructions.
Is it planned to fix variable-length instruction display in the way where instruction appearance relies on GDB '-data-disassemble' command outcome? Obviously, fixed-length display is not flexible as there are many architectures with variable-length opcodes.
