I maintain the libbinaryen package on OPAM, and we encountered an issue with “could not create compact unwind” last year. We opened an issue on ocaml and Xavier told us that we had to add -cc clang++ as ocamlopt flags, which we did in our tests (can’t link because of link limit); however, as I’ve begun to update to binaryen version_104, these warnings reappeared. At the current draft PR, I’m seeing the following warnings:
ld: warning: could not create compact unwind for _caml_start_program: dwarf uses DW_CFA_same_value
ld: warning: could not create compact unwind for _caml_raise_exn: stack subq instruction is too different from dwarf stack size
ld: warning: could not create compact unwind for _caml_raise_exception: stack subq instruction is too different from dwarf stack size
I’m wondering, what is the culprit here? It could very well be binaryen changing something, but I asked @EduardoRFS and he said I should ask here.
It is not quite clear from your message. Irrespective of the warning, does the code work or not?
If it works, I would not worry too much about it. As the warning implies, it is just the linker failing to create compact unwind data from the dwarf unwind data. This might just make exception handling a bit slower, as the unwinder will hence use the dwarf unwind data.
What surprises me is that I thought Apple developers had given up on trying to automatically convert dwarf to compact, as it was way too fragile and led to broken binaries in practice. Nowadays, the linker should directly use whatever unwind format the compiler produced. Could it be that you are using an old linker?
Thanks! I’m pretty sure we are on one of the newer MacOS running on GitHub Actions.
I’m actually adding some new flags to make this go away; hopefully they are correct. In https://github.com/grain-lang/binaryen.ml/pull/136, I’m adding -cclib -Wl,-keep_dwarf_unwind -cclib -Wl,-no_compact_unwind to our (ocamlopt_flags) stanza.
