The usage and value of MagicInstructionArchitectureDetailsFieldOffset

[hollowdrutt]

Capstone.NET/Gee.External.Capstone/NativeCapstone.cs

Line 52 in 1ed8e25

private const int MagicInstructionArchitectureDetailsFieldOffset = 80;

I've been struggling a bit with trying to use a newer version of capstone than v4 to be able to use the MOS65XX disassembler and I had some problems with accessing the architecture specific details.
It seems to me that the magic 80 byte offset is caused by the padding of the struct to make the union of architecture details align in memory.
Using the /d1reportSingleClassLayout command line option in Visual C++ on source code in the v4 branch of capstone shows an 80 byte offset to the architecture detail

C:\User\code\capstonev4\msvc\test_m68k>cl ..\..\tests\test_m68k.c /TP /I"..\..\include" /I"..\headers" /d1reportSingleClassLayoutcs_detail
Microsoft (R) C/C++ Optimizing Compiler Version 19.29.30040 for x86
Copyright (C) Microsoft Corporation.  All rights reserved.

test_m68k.c

class cs_detail size(1848):
        +---
 0      | regs_read
24      | regs_read_count
        | <alignment member> (size=1)
26      | regs_write
66      | regs_write_count
67      | groups
75      | groups_count
        | <alignment member> (size=4)
80      | cs_x86 x86
80      | cs_arm64 arm64
80      | cs_arm arm
80      | cs_m68k m68k
80      | cs_mips mips
80      | cs_ppc ppc
80      | cs_sparc sparc
80      | cs_sysz sysz
80      | cs_xcore xcore
80      | cs_tms320c64x tms320c64x
80      | cs_m680x m680x
80      | cs_evm evm
        +---

And doing the same in the capstone next branch shows 88 bytes

class cs_detail size(1856):
        +---
 0      | regs_read
32      | regs_read_count
        | <alignment member> (size=1)
34      | regs_write
74      | regs_write_count
75      | groups
83      | groups_count
        | <alignment member> (size=4)
88      | cs_x86 x86
88      | cs_arm64 arm64
88      | cs_arm arm
88      | cs_m68k m68k
88      | cs_mips mips
88      | cs_ppc ppc
88      | cs_sparc sparc
88      | cs_sysz sysz
88      | cs_xcore xcore
88      | cs_tms320c64x tms320c64x
88      | cs_m680x m680x
88      | cs_evm evm
88      | cs_mos65xx mos65xx
88      | cs_wasm wasm
88      | cs_bpf bpf
88      | cs_riscv riscv
        +---

Don't know if there is anything to be done in the Capstone.NET source code, but at least I want to give a heads up for anyone trying to use a newer version of capstone.

[9ee1]

Hi and thanks for reporting this. Like you, I too am not sure if there is anything we can do to account for this between different versions of Capstone.

In addition to this issue, its worth pointing out that any changes to structures in native Capstone APIs will generally break Capstone.NET. From my experience Capstone does tend to break backwards compatibility between major versions. I fully expect the next version to be incompatible with v4 (at least for some dissemblers).

My solution to this has been to release newer versions of Capstone.NET that align/support specific versions of Capstone. If there are suggestions for an improved method, please let me know. PRs are welcome :)