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 #2 (comment)

[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: capstone-engine/capstone#2067