Update to llvmorg-13.0.1

[hainest]

I've been trying to update the main branch to the LLVM 13.0.1 release tagged at llvmorg-13.0.1, but I've not been successful as I keep running into merge conflicts. On the surface, it looks like the last update (#1) was done as a rebase. Does anyone know if any history was re-written there? It wasn't immediately obvious that it was when I diffed against llvm-project/main.

1. Is llvm-capstone/main supposed to be an identical clone of llvm/llvm-project/main?
2. Should llvm-capstone/main be fast-forwardable to llvm?
3. What is the maintenance plan for keeping the auto-sync-update branch on top of llvm-capstone/main once the requisite changes in capstone/1803 are ready?

Thanks!

[kabeor]

Hi! For now, this repo adds code for capstone basing on llvm/llvm-project@760d4d0 , you can diff our repo with this llvm branch to see what we added. Basicly, we just add code in llvm/utils/TableGen.

Answer question:

• 1. Is llvm-capstone/main supposed to be an identical clone of llvm/llvm-project/main?
     Yes, and we hope to sync this repo with latest LLVM Released Tag.
• 2. Should llvm-capstone/main be fast-forwardable to llvm?
     If you mean are we going to PR this repo to llvm-project, maybe. But actually we still have no plan for this.
• 3. What is the maintenance plan for keeping the auto-sync-update branch on top of llvm-capstone/main once the requisite changes in Automate architecture synchronization with latest LLVM capstone#1803 are ready?
     After done everything I metioned in Automate architecture synchronization with latest LLVM capstone#1803 (comment) , we will keep this repo sync with latest LLVM Released Tag. And as you see Automate architecture synchronization with latest LLVM capstone#1803 still unsupport x86/64 etc. architectures, we hope it can be possible.

[hainest]

Hi! For now, this repo adds code for capstone basing on llvm/llvm-project@760d4d0 , you can diff our repo with this llvm branch to see what we added. Basicly, we just add code in llvm/utils/TableGen.

Answer question:

* 1. Is llvm-capstone/main supposed to be an identical clone of llvm/llvm-project/main?
     Yes, and we hope to sync this repo with latest LLVM Released Tag.

This is what I am trying to do now, but it's not identical to llvm/llvm-project/main which is why I'm getting merge conflicts.

* 2. Should llvm-capstone/main be fast-forwardable to llvm?
     If you mean are we going to PR this repo to llvm-project, maybe. But actually we still have no plan for this.

Oh, no, sorry. I meant can we do git merge --ff-only llvm-project/main? Currently, that is not possible due to merge conflicts.

* 3. What is the maintenance plan for keeping the auto-sync-update branch on top of llvm-capstone/main once the requisite changes in [Automate architecture synchronization with latest LLVM capstone#1803](https://github.com/capstone-engine/capstone/pull/1803) are ready?
     After done everything I metioned in [Automate architecture synchronization with latest LLVM capstone#1803 (comment)](https://github.com/capstone-engine/capstone/pull/1803#issuecomment-1019642411) , we will keep this repo sync with latest LLVM Released Tag.

Right, but what is the preferred technique for doing that? Once you integrate the changes from the auto-sync-update branch, the 'main' branch here will never be fast-forwardable. Do you plan to do a rebase for each new LLVM release? A merge commit?

And as you see Automate architecture synchronization with latest LLVM capstone#1803 still unsupport x86/64 etc. architectures, we hope it can be possible.

Yup. That is what I'm ultimately working on because llvm-13.0.1 has updates to the x86 TableGen data that I need in Dyninst. :)

[kabeor]

We have rebased to llvm-tag-13.0.1 yesterday, you can check that at dev branch.

About how to merge from llvm, I still haven't more ideas. Plz feel free to share your thinking.
Considering that LLVM-project is very large, we should find a way to only keep LLVM-project/llvm folder but still with commit history.

Obviously, there are a lot of works need to do. I will create a TODO list or RoadMap ASAP. It would be great if people in the community could participate in the development.

[hainest]

We have rebased to llvm-tag-13.0.1 yesterday, you can check that at dev branch.

Excellent! I'll start working on updating the x86 data from the tableGen files.

About how to merge from llvm, I still haven't more ideas. Plz feel free to share your thinking. Considering that LLVM-project is very large, we should find a way to only keep LLVM-project/llvm folder but still with commit history.

Without pushing the capstone changes upstream to LLVM, you'll always have the chance of merge conflicts. In this case, I would recommend creating a merge commit to pull in new updates from llvm-project/main and resolve conflicts at that time. Of course, git merge --ff-only would be best. :) Rebasing a community development branch like llvm-capstone/dev or llvm-capstone/main is always a headache because of history rewriting.

Obviously, there are a lot of works need to do. I will create a TODO list or RoadMap ASAP. It would be great if people in the community could participate in the development.

Definitely! I am trying to create a workflow that can update the x86 files through the proposed auto-sync mechanism. I would also like to add more instruction semantics information to the capstone tables either from LLVM's tablegen files or from Xed.

Do you have a release timeline for v5.0 of Capstone?

[kabeor]

Cool:)

We still don't have an accurate timeline, but we are planing to release v5.0 after merge this "Automate architecture synchronization" function.

[XVilka]

Just a heads up - LLVM-14.0.0 was released, it probably makes sense to use it as a base now.

[hainest]

@XVilka Agreed.

@kabeor Would it be possible to add some documentation on how you prefer to merge upstream LLVM changes so that others can help keep this repo up-to-date?

[XVilka]

@hainest Since the LLVM was updated to 16.0.x and the auto-sync PR is nearly ready to be merged, closing this: capstone-engine/capstone#1949 (comment)