Update to llvmorg-13.0.1
hainest opened this issue · comments
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.
- Is llvm-capstone/main supposed to be an identical clone of llvm/llvm-project/main?
- Should llvm-capstone/main be fast-forwardable to llvm?
- 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!
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:
-
- 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.
- Is llvm-capstone/main supposed to be an identical clone of llvm/llvm-project/main?
-
- 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.
- Should llvm-capstone/main be fast-forwardable to llvm?
-
- What is the maintenance plan for keeping the auto-sync-update branch on top of llvm-capstone/main once the requisite changes in capstone-engine/capstone#1803 are ready?
After done everything I metioned in capstone-engine/capstone#1803 (comment) , we will keep this repo sync with latest LLVM Released Tag. And as you see capstone-engine/capstone#1803 still unsupport x86/64 etc. architectures, we hope it can be possible.
- What is the maintenance plan for keeping the auto-sync-update branch on top of llvm-capstone/main once the requisite changes in capstone-engine/capstone#1803 are ready?
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. :)
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.
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?
Cool:)
We still don't have an accurate timeline, but we are planing to release v5.0 after merge this "Automate architecture synchronization" function.
Just a heads up - LLVM-14.0.0 was released, it probably makes sense to use it as a base now.
@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)