jakehehrlich added a comment. > The strong motivation here is to avoid having the list be maintained outside > of the source code. I am not too strongly tied to the YAML approach as long > as the binaries that we get at the end are equivalent to the pruned ELF > binaries from the YAML2ELF approach. However, the trade off here is valuable > - it allows for the source code to be the source of truth for the interface > set. The intermediate emission is due to the fact that this requires program > level visibility and having the intermediates an extra step to merge is > relatively simpler. In fact, you could emit the TBE files from this and check > that into the tree if you really wanted (but allowing the source to remain > the source of truth I think is a valid and valuable trade off). The reason > for the selection of YAML is simply pragmatism - that is already available in > the tree. If the TBE linker is available now, I have no issue with that being > the intermediate representation (assuming that the representation is easy to > parse programatically).
You can verify that a .tbe file is consistent with the finally fully linked executable to ensure that it is consistent with the actual source of truth, the finally linked binary (the source code is not really the source of truth on this since compiler and linker flags alter these things). This is a planned feature of llvm-elfabi. Keep in mind that having .tbe files in tree means that you can also review the public interface of modules exactly as a part of code review which your method allows for only in the traditional way. When you consider that compiler and linker flags can change these things there is no one single source of truth that humans can easily look at without something like the .tbe files. This was a major motivation behind the choice here. The tbe format is not suitable as a pre-merged format I think. I propose that you could take your pre-merged format and do the merging in llvm-elfabi (or rather, the tool would be a symlink to the same binary with a different name) to produce the same internal representation that llvm-elfabi already uses and then you could use the same writers for both .tbe and ELF stubs. This would allow sharing of the relevant code and would trivially allow both .tbe files and stubs to be produced. Also, as a side note, .tbe files are also YAML for the same reason you're using it here. I don't have an issue with that. Repository: rC Clang CHANGES SINCE LAST ACTION https://reviews.llvm.org/D60974/new/ https://reviews.llvm.org/D60974 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
