[lld] r332308 - [WebAssembly] Allow signautre of entry function to be flexible

[Sam Clegg via llvm-commits]

On Wed, May 16, 2018 at 4:51 PM, Dan Gohman <sunfish at mozilla.com> wrote:
>
>
> On Mon, May 14, 2018 at 7:00 PM, Sam Clegg <sbc at google.com> wrote:
>>
>> On Mon, May 14, 2018 at 6:15 PM, Dan Gohman <sunfish at mozilla.com> wrote:
>> > Hi Sam,
>> >
>> > Sorry for the late arrival here. Are there use cases that need flexible
>> > signatures? It seems like even if we can support it now, it's not
>> > immediately obvious that we're always going to want to support it in the
>> > future.
>>
>> The common use cases that I'm looking at are emscripten, and the wasm
>> waterfall test
>> which both basically do `--entry=main`.  Without this change this
>> means every program
>> would generate a linker warning about the entry point signature not
>> being correct.
>
>
> When using `--entry=main`, do you know what gets passed as the `argc` and
> `argv` to main?
>

The embedder is free to pass whatever they want to the exported function, right?

The primary purpose of providing a --entry it to let the linker know
that this symbol should be exported and acts as a GC root for function
GC.   Its pretty much identical to the '--undefined=foo` +
'--export=foo'.

Both emscripten and the waterfall test driver want to export 'main' +
'__wasm_call_ctors' and call them directly.  Currently they do
'--entry=main --export=__wasm_call_ctors'.  If entry we revert this
change they would both need to switch to using: '--no-entry
--undefined=main --export=main --export=__wasm_call_ctors'.  This
works because neither --export not --undefined care about signatures.

>>
>> This change is mostly to allow these use cases and suppress the
>> warning in this case.
>> If we update those two consumers I could see us reverting this change
>> perhaps.  Is that
>> what you are suggesting?
>
>
> Yeah. If those are the only two consumers (that we know of), then updating
> those consumers and going back to checking the signature seems desirable.
> It's consistent with wasm in general, which is strict about signatures. And,
> it would reduce the set of functionality we have to support.
>
> Dan
>
>