I’d like to expand the current libc++ symbol checker to include libc++abi and libunwind.
I’ve noticed there is a TODO on the current libc++ symbol checker, which states that the check should be a lit test instead (llvm-project/run-buildbot at main · llvm/llvm-project · GitHub).
I don’t think it makes sense to copy the implementation of the libc++ checker if we plan on changing it entirely down the road. Therefore, I actually have 2 objectives:
- Replace the symbol checker CMake target with a lit test (per the TODO).
- Allow the abi symbol checker support additional runtimes (libunwind, libc++abi) via additional lit tests.
There are 3 steps to take:
- Start by making the current checker logic more generic (i.e. moving the related files out of the
libcxx/ directory).
- Convert the CMake target to a lit test that performs the same/similar task.
- Create a lit test for libunwind and libc++abi respectively.
I’ve outlined some more info in this patch, which implements the first of the three steps: ⚙ D148753 [libcxx] move abi symbol checker logic to generic location.
Please give me your thoughts on this plan.
I think this makes sense! Thanks, I put the TODO in there and I would love to see it resolved. I’ll chime in on ⚙ D148753 [libcxx] move abi symbol checker logic to generic location with comments.
I recently implemented a similar script for compiler-rt in ⚙ D150051 [compiler-rt][profile] Script for ABI checking. I initially tried to re-use the libc++ script but I couldn’t get it to work on static archives. I then tried to use the recently implemented JSON output support in llvm-readobj and that turned out be both reliable, both for shared and static libraries, but also very straightforward.
For now, the script in ⚙ D150051 [compiler-rt][profile] Script for ABI checking only supports ELF (since the --elf-output-style=JSON option in llvm-readobj is ELF specific), so it’s not a complete replacement for the existing libc++ script, but I hope that we’ll implement JSON output support for Mach-O and COFF as well at which point this script could replace the libc++ one (or we could consider merging them).
Another potential direction might be to extend llvm-ifs with static library support and then use llvm-ifs directly.
That’s really cool! Actually I think we should go the llvm-ifs way if we can. There are other benefits to providing ifs files, for example we use them in our SDK and having an upstream way of generating those for libc++ would be really great. And then the ABI check can be a very simple « generate ifs file and diff against the existing one ».