CS_ARCH_TRICORE?

[arkup]

Hi, which fork of the capstone framework are you using? I see in the src:

err_no = cs_open(CS_ARCH_TRICORE, (cs_mode)0, handle);

but capstone is not official supporting tricore(?)

/// Architecture type
typedef enum cs_arch {
    CS_ARCH_ARM = 0,    ///< ARM architecture (including Thumb, Thumb-2)
    CS_ARCH_ARM64,      ///< ARM-64, also called AArch64
    CS_ARCH_MIPS,       ///< Mips architecture
    CS_ARCH_X86,        ///< X86 architecture (including x86 & x86-64)
    CS_ARCH_PPC,        ///< PowerPC architecture
    CS_ARCH_SPARC,      ///< Sparc architecture
    CS_ARCH_SYSZ,       ///< SystemZ architecture
    CS_ARCH_XCORE,      ///< XCore architecture
    CS_ARCH_M68K,       ///< 68K architecture
    CS_ARCH_TMS320C64X, ///< TMS320C64x architecture
    CS_ARCH_M680X,      ///< 680X architecture
    CS_ARCH_EVM,        ///< Ethereum architecture
    CS_ARCH_MOS65XX,    ///< MOS65XX architecture (including MOS6502)
    CS_ARCH_WASM,       ///< WebAssembly architecture
    CS_ARCH_BPF,        ///< Berkeley Packet Filter architecture (including eBPF)
    CS_ARCH_RISCV,          ///< RISCV architecture
    CS_ARCH_MAX,
    CS_ARCH_ALL = 0xFFFF, // All architectures - for cs_support()
} cs_arch;

[sidneyp]

Hello! TriCore is not official in capstone framework. We have llvm-tricore and a forked repository of aquynh/capstone. I updated the README.md saying that those are our dependencies. If you install our capstone and llvm-tricore as stated in README.md, the ditricore is going to work.

[arkup]

cool! thanks I will try it. BTW. Would be great if you could send pull req to capstone so they officially support tricore.

[XVilka]

@arkup The full support of Tricore was added into the mainstream capstone: https://github.com/capstone-engine/capstone/tree/next/arch/TriCore

Feel free to try and report any bugs if there are any.

See also https://github.com/TriDis/ditricore/issues/2#issuecomment-1600261757

[arkup]

@XVilka Thank you for adding support for Tricore. I conducted a quick test, and it works fine, well done.

There is one thing I dislike : the "%" symbol prepended to the registry name. I assume that it may be intended to distinguish better e.g. "a15" from "#0xa15," but it confuses me when transitioning from IDA, Ghidra, Lauterbach. It would be appreciated to use unified formatting or if a cs_option could be implemented to automatically remove the "%" symbol from the register name and prepended # before hex number e.g. addi %d0, %d0, 0x1110 -> addi d0, d0, #0x1110

[XVilka]

@imbillow what do you think about that? It's different from other architectures in Rizin as well, maybe we could change it before the 5.0 release?

[imbillow]

@XVilka Thank you for adding support for Tricore. I conducted a quick test, and it works fine, well done.

There is one thing I dislike : the "%" symbol prepended to the registry name.

I assume that it may be intended to distinguish better e.g. "a15" from "#0xa15," but it confuses me when transitioning from IDA, Ghidra, Lauterbach. It would be appreciated to use unified formatting or if a cs_option could be implemented to automatically remove the "%" symbol from the register name and prepended # before hex number

e.g. addi %d0, %d0, 0x1110 -> addi d0, d0, #0x1110

cc @XVilka

I referred to the disassembly style of objdump, which can be easily changed if desired. However, considering that the existing tests are also in this style, it feels a bit troublesome.

[XVilka]

Objdump uses AT&T style by default, while many prefer Intel style, which is the default everywhere else outside binutils.

existing tests are also in this style, it feels a bit troublesome.

Maybe some simple python script could help with renaming?

@wargio @ret2libc @thestr4ng3r do you have any opinion on the matter?

[wargio]

we could implement it

[XVilka]

we could implement it

@wargio implement what? Sorry I don't understand without details.

[wargio]

Add the implementation to change the "assembly style". this should be an easy task in any language.

[ret2libc]

If most other architectures, like ARM, are using the style with addi d0, d0, #0x1110 I think TriCore should support it as well.

[XVilka]

@imbillow so, I guess the consensus that removing % would be better. Could you please quickly do that and send a PR to Capstone while they didn't release 5.0 yet?

[XVilka]

@kabeor please wait for this before tagging

[kabeor]

@XVilka Sure. I was going to release at Saturday morning.

[imbillow]

@imbillow so, I guess the consensus that removing % would be better. Could you please quickly do that and send a PR to Capstone while they didn't release 5.0 yet?

I'm sorry. Due to some personal matters at home, I will not be able to submit code for the next few days (estimated 3-7 days).

[kabeor]

@imbillow Don't worry, we can wait for it.

[XVilka]

@imbillow so, I guess the consensus that removing % would be better. Could you please quickly do that and send a PR to Capstone while they didn't release 5.0 yet?

I'm sorry. Due to some personal matters at home, I will not be able to submit code for the next few days (estimated 3-7 days).

No worries, I will do it tonight.

[imbillow]

@imbillow so, I guess the consensus that removing % would be better. Could you please quickly do that and send a PR to Capstone while they didn't release 5.0 yet?

I'm sorry. Due to some personal matters at home, I will not be able to submit code for the next few days (estimated 3-7 days).

No worries, I will do it tonight.

By the way, in most cases, just modifying 'TriCoreInsnPrinter.c' will be enough, which should be fairly easy. However, some instructions have implicit register operands (like '%a15'), for which I hardcoded the '%' in the tablegen files. This might be a bit troublesome.

[XVilka]

Sent a PR here: https://github.com/capstone-engine/capstone/pull/2067