This is an archive of the discontinued LLVM Phabricator instance.

[WebAssembly] Make function signature checks into warning
AbandonedPublic

Authored by sbc100 on Jan 29 2018, 11:26 AM.

Details

Reviewers
ruiu
Summary

Also add --fatal-warnings to match the ELF and COFF backend
behaviour.

Event Timeline

sbc100 created this revision.Jan 29 2018, 11:26 AM
ncw added a subscriber: ncw.Jan 29 2018, 1:30 PM

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.

In D42652#991125, @ncw wrote:

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?

ncw added a comment.Jan 29 2018, 2:03 PM

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.

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.

sbc100 abandoned this revision.Jan 29 2018, 2:36 PM

I think I'm going to abandon this change because I'm artificially creating a warning where we have none otherwise. Seems backwards.

sbc100 added a comment.May 4 2018, 5:33 PM

Resurrected this in a slightly different form: https://reviews.llvm.org/D46484