yota9
commented
2 years ago Hello @maksfb ! Thank you for your post! I'm currently preparing to open source golang support, I believe it will be soon, so I hope we will be able to do it before global bolt refactoring :) I will give more details about it in about a week or so here, I will need to prepare a few more places, that time there are already few patches prepared and pull requests are opened, I hope we will be able to merge them soon. Thank you!
rafaelauler
aaupov
I am opening this issue to give a heads-up for all BOLT developers of the upcoming refactoring work we will be pushing in the next couple of weeks. We will break BOLT into multiple components (CORE, IR, Debug, etc.) that will affect the directory structure and will allow using shared-library build mode. The concrete names and the directory structure are not finalized yet. All suggestions are welcome.
In parallel, we will be modifying parts of the IR itself. One thing that comes to mind and that I have wanted to change for a long time is the way
BinaryFunctions are stored. The containing map assumes that every function has an address. That was true at one point, but then we started injecting new functions in a binary and adding more files. For PIC code (.so's), e.g. two files can have the same input address creating a conflict in the binary context. We keep finding more reasons to decouple the input address information from the way functions are stored, and the time has come to refactorBinaryContext::BinaryFunctions.I know there are a big set of patches in the pipeline that are not part of the work at FB, e.g. the support for golang. So please cope with us, as I can imagine you will have to modify your code for the refactoring. If you were planning to create pull requests soon, perhaps you can prioritize them, and we can hold the refactoring for some time.