The disassembly view dosen't show opcode

[ljw66]

The disassembly view dosen't show opcode

[TommyMurphyTM1234]

Isn't that an option in the GUI to display the opcodes?

• https://mcuoneclipse.com/2015/07/22/show-opcodes-in-eclipse-disassembly-view/

[ljw66]

Isn't that an option in the GUI to display the opcodes?

• https://mcuoneclipse.com/2015/07/22/show-opcodes-in-eclipse-disassembly-view/

Thanks for your help. That's it, in the second image, I didn't click show opcodes and there is no opcodes. But in the third picture, I clicked the show opcodes option. The result is address column move right a little. But still no opcodes.

[TommyMurphyTM1234]

What version of the various tools are you using as per the issue template?

Versions

• [plug-in version]
• [Eclipse version]
• [Java version]
• [operating system]
• [toolchain version]

[ljw66]

eclipse version: 2022-12 (4.26.0)
plugin-in version: 6.3.1.202210101738
java version: 17
toolchain version: Xuantie-900-gcc-elf-newlib-mingw-V2.6.1
operating system: windows 11

[TommyMurphyTM1234]

toolchain version: Xuantie-900-gcc-elf-newlib-mingw-V2.6.1

What happens if you use the xPack RISC-V GCC toolchain?

• https://xpack.github.io/dev-tools/riscv-none-elf-gcc/

[ljw66]

Due to the special chip used now, only this toolchain can be used for compilation. The xPack RISC-V GCC toolchain fail to support some comipile flags.

[TommyMurphyTM1234]

Due to the special chip used now, only this toolchain can be used for compilation. The xPack RISC-V GCC toolchain fail to support some comipile flags.

OK, but you need to determine if the issue is due to the toolchain rather than the Embedded CDT plugins.

[ljw66]

Alright, thank you very much!

[TommyMurphyTM1234]

I tried the following but neither see opcodes in the Disassembly view (when debugging a RISC-V RV64 program on QEMU) nor any option to show opcodes in the view menu or global preferences.

• Eclipse IDE for Embedded C/C++ Developers 4.27.0.20230309-1200
• Embedded C/C++ Core 6.3.2.202304281106

I also have these xPacks installed after creating a RISC-V template project:

tommy@gannet:~$ xpm list --global
- @micro-os-plus/architecture-riscv
  A source library xPack with the µOS++ RISC-V architecture port
  - 4.1.0
- @micro-os-plus/build-helper
  A source library xPack to assist the µOS++ builds
  - 2.11.0
- @micro-os-plus/devices-qemu-riscv
  A source xPack with <your-description-here>
  - 1.0.1
- @micro-os-plus/diag-trace
  A source library xPack with the µOS++ trace::printf() tracing infrastructure
  - 4.1.1
- @micro-os-plus/hello-world-qemu-template
  A source xPack  / npm package with a template to generate semihosted Hello World projects running on QEMU
  - 1.4.1
- @micro-os-plus/semihosting
  A source library xPack with the µOS++ portable semihosting definitions
  - 8.0.0
- @micro-os-plus/startup
  A source library xPack with the µOS++ startup code for bare-metal platforms
  - 5.2.0
- @xpack-dev-tools/arm-none-eabi-gcc
  A binary xPack with the GNU Arm Embedded GCC toolchain executables
  - 12.2.1-1.2.1
- @xpack-dev-tools/cmake
  A binary xPack with the CMake executables
  - 3.21.6-1.1
- @xpack-dev-tools/ninja-build
  A binary xPack with the Ninja Build executables
  - 1.11.0-1.1
- @xpack-dev-tools/qemu-arm
  A binary xPack with QEMU Arm executables
  - 7.2.0-1.1
- @xpack-dev-tools/qemu-riscv
  A binary xPack with QEMU RISC-V executables
  - 7.0.0-1.1
  - 7.2.0-1.1
- @xpack-dev-tools/riscv-none-elf-gcc
  A binary xPack with the GNU RISC-V Embedded GCC executables
  - 12.1.0-2.1
  - 12.2.0-3.1

I'm running on Zorin OS Lite 16.2 (a Ubuntu 20.04 LTS derivative distro).

[TommyMurphyTM1234]

Apologies - I missed that you click on the address column in the Disassembly view in order to get the Show Opcodes option.

As you can see here, using the set of tools that I listed earlier - including the latest xPack RISC-V embedded GCC - the opcodes are displaying correctly.

So, I can only infer that the original issue is due to the use of the different toolchain:

Xuantie-900-gcc-elf-newlib-mingw-V2.6.1

[ilg-ul]

Thank you, Tommy, for taking the time to investigate this.

Since I don't know how the custom toolchain was built, I can't provide much help with it.

But if I'd had to diagnose this, I would do the following:

• install a fresh Eclipse Embedded CDT in a new folder
• create a new workspace
• instantiate the Hello World RISC-V QEMU xPack C/C++ Project (for more info, see https://eclipse-embed-cdt.github.io/templates/hello-world-qemu-xpack/)
• (wait for the RISC-V toolchain to download, if not pre-loaded, as the documentation instructs))
• run a debug session via QEMU

If the opcodes are shown, this is a confirmation that the Eclipse environment is ok.

Then import the actual project, configure the custom toolchain, and retry the debug session.

If it works as expected (and as proved before), you most probably had a problem with the Eclipse environment.

If the problem persist, the probability to have a problem with the toolchain is pretty high.

Hope it helps.

[TommyMurphyTM1234]

FWIW I also downloaded the latest T-Head toolchain:

• https://github.com/T-head-Semi/xuantie-gnu-toolchain/releases/tag/2023.03.21

and configured the template RISC-V project to use that instead of the xPack one and I was also able to see the opcodes in the Disassembly view using that setup.

Maybe the issue is with this specific toolchain (I don't know where it is available) and/or Windows or something?

Xuantie-900-gcc-elf-newlib-mingw-V2.6.1

[ilg-ul]

Or, as I suspected, a problem with the Eclipse or Eclipse workspace?

[TommyMurphyTM1234]

Xuantie-900-gcc-elf-newlib-mingw-V2.6.1

Yes - good point.

[ljw66]

I compared disassembled code generated by different toolchains. I found out that my toolchain uses big endian mode. But eclipse only show little endian. This makes it impossible to display the operand. Thank for everyone's suggestions.

[ilg-ul]

I found out that my toolchain uses big endian mode.

What a regrettable design :-(

But eclipse only show little endian.

I don't remember doing anything special in Eclipse Embedded CDT for this, the behaviour is probably inherited from CDT.

[ljw66]

I think so. Thanks again :）