tracy
tracy copied to clipboard
wolfpld
(Do not submit) - draft for adapting to capstone arm64 renaming
FYI @wolfpld: Capstone has just done a breaking renaming: ARM64 --> AArch64 (https://github.com/capstone-engine/capstone/pull/2026)
This PR is a good-enough local patch for anyone trying to build against latest Capstone. It uses Capstone's own provided compatibility macros to resolve to either the old or the new identifiers.
The problem which IIUC makes this PR not good to merge is that by relying on these Capstone macros... it probably doesn't actually support older Capstone versions, which presumably don't have these macros.
You probably need to resolve that by forking these macros on the Tracy side...
@bjacob Just stumbled on this. Capstone v5 and v4 have those macros now. See capstone.h in each branch.
oooh! I also hit the same issue! It seems that I should maybe just build capstone v5, but not next? Let me give it a shot..
@hanhanW Mind that v5 is pretty out of date already. It is based on LLVM 7, misses some Aarch64 extensions and has some bugs. We have a guide regarding the upcoming v6 if you want to take a look.
@hanhanW Mind that
v5is pretty out of date already. It is based on LLVM 7, misses some Aarch64 extensions and has some bugs. We have a guide regarding the upcoming v6 if you want to take a look.
I'm good with v5 for now because I don't need to jump into asm level at this moment. I mainly wanted to address compilation issues when building tracy with IREE. Thanks for the heads-up!
@wolfpld, it seems that multiple people have hit this. Would you suggest merging some flavor of this (do you want to suggest changes to this draft) ?
@bjacob Just stumbled on this. Capstone v5 and v4 have those macros now. See capstone.h in each branch.
I'm not sure that we can count on all users' package managers to have received the backport.
The guaranteed thing that we can do here is, as suggested in the PR description, fork those CS compatibility macros on the Tracy side.
https://github.com/wolfpld/tracy/pull/707 should solve this.
From a cursory look --- it looks like this hardcodes Capstone 5.0.1 ? I actually need to use Capstone 6 to use recent ISA extensions. Doing so would require Tracy-side source changes as in the present PR, right ?
Looks like a good step though, from where the capstone 5->6 move could be made as a second step ? Given the headache that capstone has been giving tracy users, I definitely welcome Tracy internalizing it.
The key thing is that it hardcodes a version, so you have one target, instead of the crapshoot that is currently the case (the :hankey: prize goes to ubububu, which ships 3.x :exploding_head:).
Yup, exactly. Once https://github.com/wolfpld/tracy/pull/707 is merged, and we've rebased our downstream to work with that, i'll rebase the present PR into a capstone 5->6 bump (which you may or may not merge, but it's useful for me even if unmerged).
Yup, exactly. Once #707 is merged, and we've rebased our downstream to work with that, i'll rebase the present PR into a capstone 5->6 bump (which you may or may not merge, but it's useful for me even if unmerged).
I'm currently updating our (IREE's) downstream to use the CMake files now present here in Tracy upstream (we'll just use the upstream build and drop our custom CMake + custom instructions, unless there is some reason to keep them that I'm not seeing). @bjacob did you want to continue with a capstone 5 -> 6 update?
Yup, that's the plan laid out at https://github.com/iree-org/iree/issues/16777. The above https://github.com/wolfpld/tracy/pull/671#issuecomment-2016830130 implies that the first step in the tasklist there is already completed, and what you describe doing is the second step in that tasklist, so after that we can bump from Capstone 5 to 6, the third step in that tasklist (the tasklist is framed in a way that assumes that the capstone 5->6 bump would be merged in upstream tracy (here) first, but if that's not desired here, we can keep that as a local tracy patch).
not a strict dependence at every step, just my suggestion how in what order to tackle things.
I am sorry, forgot to drop it here. But we have a compatibility header now. Though, it is still a PR until the other maintainers manage to look at it: https://github.com/capstone-engine/capstone/pull/2321