Closed aheejin closed 1 year ago
Looks like this is failing in CI.
Does this repo use tot LLVM version of yaml2obj?
Yes, but we are pinned to a specific version, see: https://github.com/google/bloaty/blob/2757d3ec0fec07f4ac7f2f96fe8f0b020c2d84fb/.github/workflows/build.yml#L25
Perhaps we need to update that version to something newer?
Yeah maybe we should. But the yaml2obj-changing commit has not been included in any of release candidates so far because it is so recent, so I opened https://github.com/llvm/llvm-project/issues/64720 to backport it to the next release, so I have to wait until it is merged. Reason I'd like to merge this is Google's internal toolchain's bloaty uses tot LLVM so it is breaking. (I think you're cc'ed in that internal bug too.)
I think it could also be possible to check out llvm at an arbitrary commit if that helps.
Ah I didn't know that. But it also looks llvmorg-17.0.0-rc3
will be tagged Aug 22nd, which is not far. It's not an official release but would look better than an arbitrary commit I guess..? If this is not urgent, I'll update the version to llvmorg-17.0.0-rc3
once it's tagged.
Can you enable the CI? Thanks!
After https://github.com/llvm/llvm-project/commit/1b21067cf247c62c2442daa7ee2d3915249d1ee2, if sections in Wasm YAML files don't have
HeaderSecSizeEncodingLen
field specified, yaml2obj will automatically pad header section to 5 bytes, which was a byproduct of fixing some llvm-objcopy issue.cc @dschuff