Fix Python bindings after changes to cs_detail

[peace-maker]

#2034 changed the regs_read array size and added a new writeback
element to the cs_detail struct.

Those changes weren't reflected in the Python bindings causing details to be missing.

I've included fixes for the RISCV and TriCore bindings as well, since they were related or popped up during testing of this change. I originally looked into the problems while testing the changes to the RISCV instruction groups #2007 in Python.

[XVilka]

@imbillow take a look at Tricore changes please

[XVilka]

@peace-maker could you please take a look at #2005 too? Since you are working on Python bindings anyway.

[XVilka]

@kabeor @imbillow @aquynh

[imbillow]

LGTM

[kabeor]

Thanks a lot! Merged.

[peace-maker]

@kabeor I think the same changes to the cs_detail structure are needed in the other language bindings too. I don't know powershell or ocaml though, so I'll leave this up to someone else actually using those bindings.

[XVilka]

@peace-maker right, problem is because they aren't tested on CI: #1984 (comment)

[peace-maker]

Are the changes to the cs_detail struct 100% required for the TriCore architecture @imbillow ? I don't see the writeback field getting used on a glance and the array size change feels like an oversight while refactoring using the defines. Maybe the struct can be reverted and the work avoided?

[XVilka]

@peace-maker it was added for compatibility with ARM, AFAIR. It's used in Rizin's RzIL uplifting code, for example: https://github.com/rizinorg/rizin/blob/dev/librz/analysis/arch/arm/arm_il64.c#L1025

[imbillow]

Are the changes to the cs_detail struct 100% required for the TriCore architecture @imbillow ? I don't see the writeback field getting used on a glance and the array size change feels like an oversight while refactoring using the defines. Maybe the struct can be reverted and the work avoided?

Those are just changes pulled from the auto-sync branch, and since the auto-sync branch hasn't been merged yet, it may indeed seem redundant for the current version of capstone.

[peace-maker]

@peace-maker it was added for compatibility with ARM, AFAIR. It's used in Rizin's RzIL uplifting code, for example: https://github.com/rizinorg/rizin/blob/dev/librz/analysis/arch/arm/arm_il64.c#L1025

Ah, that accesses the field in the cs_arm64 detail struct though instead of using the newly added writeback field on the base cs_detail struct though. That looks redundant indeed, but I haven't looked at the auto-sync branch yet and I might be way off. Just wanted to point it out while stumbling over it in the capstone code.

[XVilka]

Are the changes to the cs_detail struct 100% required for the TriCore architecture @imbillow ? I don't see the writeback field getting used on a glance and the array size change feels like an oversight while refactoring using the defines. Maybe the struct can be reverted and the work avoided?

Those are just changes pulled from the auto-sync branch, and since the auto-sync branch hasn't been merged yet, it may indeed seem redundant for the current version of capstone.

@Rot127 what do you think about that? Is it necessary path in current auto-sync state?

[Rot127]

what do you think about that? Is it necessary path in current auto-sync state?

If it isn't used in TriCore we can remove it for the v5 release I guess.

But for auto-sync it is definitely useful, because:

1. This writeback variable was duplicated for each arch in their detail struct.
2. We add the concept of operand binding from LLVM (which implies writeback). So more archs will use it in the future.