Also add --fatal-warnings to match the ELF and COFF backend
behaviour.
Details
Diff Detail
- Repository
- rLLD LLVM Linker
- Build Status
Buildable 14344 Build 14344: arc lint + arc unit
Event Timeline
Sorry to poke my nose in, I'm just curious as to the rationale on why this shouldn't be a link error? We know for certain at this point that the output Wasm file won't validate, so we have effectively failed to link the inputs together.
Mostly because turning it on breaks so much existing code. For example, musl has several such issues in it, which would mean that most of our tests on the wasm waterfall would stop linking if we enable this today. For what its worth this is completely off by default right now. So unless you explictly ask for it the linker will be silent about these errors.
I think it is a worthy goal to enable this by default one day.
Mostly I was looking for a warning to test the --fatal-warnings flag and these seemed like a good one because I imagine turning on by default as a warning first. AFAICT there are no other warnings in the wasm linker today.. so maybe we don't need this flag at all?
Ah, now I see! Thanks. There can't be many broken prototypes in Musl? I'm aware of one, where __libc_start_main is called with an intentionally wrong prototype, but that can be fixed with an arch-specific override. It's still a bit off if it currently works, since the resulting Wasm file won't be runnable if the types don't match.
Perhaps some of the errors are instances of the bug (https://bugs.llvm.org/show_bug.cgi?id=35385), which results in correct declarations getting a messed-up signature mismatch.
The biggest culprit I've seen so far is the declaration of main() itself. We are talking about special casing this in the frontend since the standard allows it to have two different signatures.
Outside of that, we need to see just how widespread the signature mismatch issue is. If it only effects a few existing projects they it might be feasible the enable this error by default and to fix those projects. If such violations are common we may need to do some more cleverness/mitigations in the linker.
Often times the resulting modules can actually be runable, if the function is called via call_indirect(). In this case the resulting program will fail at run time rather than validation time, and only if that particular function is called. One can imagine a project that includes such code, but in practice never execute it. Indeed this is the case for musl, which calls main, but indirectly in its _start function. As long as we don't actually call its start (i.e if we call main() directly instead) that module is still usable.
I think I'm going to abandon this change because I'm artificially creating a warning where we have none otherwise. Seems backwards.