Difference between revisions of "Development:StructPackVerifier"
m (Add development category) |
|||
| (One intermediate revision by one other user not shown) | |||
| Line 28: | Line 28: | ||
*** libc6-dev | *** libc6-dev | ||
*** linux-libc-dev | *** linux-libc-dev | ||
| + | *** libc6-dev-amd64-cross | ||
| + | *** linux-libc-dev-amd64-cross | ||
| + | *** libstdc++6-amd64-cross | ||
| + | *** libstdc++-10-dev-amd64-cross | ||
** AArch64 Linux | ** AArch64 Linux | ||
*** libc6-dev-arm64-cross | *** libc6-dev-arm64-cross | ||
| Line 48: | Line 52: | ||
The libclang python implementation might not be all encompassing of definitions. So one should be careful to only throw basic struct and union types at the tooling. | The libclang python implementation might not be all encompassing of definitions. So one should be careful to only throw basic struct and union types at the tooling. | ||
Ideally only POD types should be compared with the expectation that structs will be crossing architecture boundaries and need to match. | Ideally only POD types should be compared with the expectation that structs will be crossing architecture boundaries and need to match. | ||
| + | |||
| + | [[Category:Development]] | ||
Latest revision as of 13:46, 22 June 2022
Struct packing verifier
The struct packing verifier python script allows us to validate struct packings match between aliases and architectures. This is necessary to ensure auto generated structs match across architectures and handwritten structs match the original architecture's struct.
Struct annotations
The verifier tool looks for structures and unions with specifically crafted annotations to only check the ones we care about.
`__attribute__((annotate("alias-<arch>-<struct name>")))`
- Where arch can be x86_32, x86_64, aarch64, win32, win64
- Struct name is the original structure name that the struct to should alias to
- eg `__attribute__((annotate("alias-x86_32-rusage")))`
`__attribute__((annotate("fex-match")))`
- If a struct should be compared across architectures then we use this to ensure it matches
- FEX will compare that the struct matches between x86-64 and aarch64 for compatibility
Dependencies
- python3
- python3-clang
- clang (required to find default include paths)
- Multilib packages
- 32bit Linux
- libc6-dev-i386-cross
- libstdc++6-i386-cross
- libstdc++-10-dev-i386-cross
- linux-libc-dev-i386-cross
- 64bit Linux
- libc6-dev
- linux-libc-dev
- libc6-dev-amd64-cross
- linux-libc-dev-amd64-cross
- libstdc++6-amd64-cross
- libstdc++-10-dev-amd64-cross
- AArch64 Linux
- libc6-dev-arm64-cross
- linux-libc-dev-arm64-cross
- libstdc++6-arm64-cross
- libstdc++-10-dev-arm64-cross
- Mingw for Windows
- g++-mingw-w64-x86-64
- g++-mingw-w64-x86-64-win32
- g++-mingw-w64-x86-64-posix
- g++-mingw-w64-i686
- g++-mingw-w64-i686-win32
- g++-mingw-w64-i686-posix
- 32bit Linux
Getting a result
If the arguments are passed in to the tool correctly then it will return 0 if everything matches, else it returns 1 if something hasn't matched. You'll then get logging output to compare against
Bugs
The libclang python implementation might not be all encompassing of definitions. So one should be careful to only throw basic struct and union types at the tooling. Ideally only POD types should be compared with the expectation that structs will be crossing architecture boundaries and need to match.