<div dir="ltr">I would opt for a simpler approach. Backward and forward compatibility complicates development and design, because with new versions the number of combinations to support grows O(N*N) . Multitude of formats further complicates things O(M*M) in the number of formats at worst.<div><br></div><div>If at each time there is 1 main format (and it's volatile over time), and a tool for conversion from a previous version is implemented via "chain of responsibility" pattern where each link converts between 2 adjacent versions, then the development is most simplified.</div><div><br></div><div>So for now only a header containing of a magic number (denoting it's XRay format) and a version number is needed. No need to predict how it goes in the future.</div><div><br></div><div>The problem of code duplication between compiler-rt and LLVM repositories due to format writer living in one and reader living in another, seems severe. I don't know a better solution than "if we have to duplicate, duplicate trivially": instead of implementing the format reader only in LLVM and format writer in compiler-rt, thus getting scattered pieces of one whole - implement both writing and reading logic in the same files, and just copy-paste the files between the repositories (or better, do this in separate directories and keep them identical in LLVM and compiler-rt). I assume that creation of a separate repository containing just the XRay common code, and making it a dependency of both LLVM and compiler-rt is not an option. Though I am curious how LLVM community was earlier solving similar problems.</div><div><br></div><div>Anything else I can help with?</div><div><br></div><div>Cheers,</div><div>Serge<br><div><br></div></div></div>