Community
Participate
Working Groups
Hi, After some trouble, I am slowly getting the CDT debugger to work with an embedded CPU simulator debugger (arm-elf-gdb.exe in my case). After successully loading an application.elf file into the debugger, and switching into disassembler mode, I get an ARM disassembly listing similar to: 0x00000660 <main+20>: mov\tr2, #2\t; 0x2 0x00000664 <main+24>: mvn\tr3, #48896\t; 0xbf00 0x00000668 <main+28>: sub\tr3, r3, #223\t; 0xdf 0x0000066c <main+32>: str\tr2, [r3] 0x00000670 <main+36>: mvn\tr2, #48896\t; 0xbf00 0x00000674 <main+40>: ldr\tr3, [r2, -#207] As it seems, the \t codes should preferably be expanded into a tab for proper column alignment. Can this be added? Furthermore, I would like to see the hex opcodes for every assembler instruction, side-by-side with the address. Could this be added as well? Kind regards, Johan Johansson
The '\t' problem has already fixed in the head branch by Chris Songer. Regarding your second request. Do you know if there is a way to retrieve the hexadecimal opcode from gdb?
Unfortunately I don't know very much about gdb, but if you know the lenght and address of every assembler instruction, it should really be a matter of reading the memory contents for X number of bytes starting at address Y for every instruction, I assume? (The opcodes is just a hex view of the memory bytes occupied by the instruction) /Johan
Yes, it is possible to read memory for each opcode but it is very time consuming. What if we use hovering instead?
OK, I think that the default behaviour in embedded debuggers really are to show the address, opcode and disasm string in parallel columns, but if it is very slow perhaps that is not viable. Perhaps a GUI choice "show opcodes on/off" could work, or even hovering tooltips as mentioned. Anyone else having any preferences on this? /Johan
You are the first who raised this question. I agree that the best solution is to show opcode values in the view and to have an "on/off" preference for it. I'll try it to see how it slows down the debugging.
PR was not targeted to any particular release. Changing target milestone to 2.1
Moving the target milestone to 3.0.
Deferred.
Reassigning to the pool.
Future means you commit to fix it in the Future. Inboxes can't make committments. Moving to '--'.
