Page MenuHomePhabricator

[WebAssembly] Add support for writing out init functions in linking section

Authored by sbc100 on Dec 18 2017, 5:40 PM.

Diff Detail

rLLD LLVM Linker

Event Timeline

sbc100 created this revision.Dec 18 2017, 5:40 PM
sbc100 updated this revision to Diff 127444.Dec 18 2017, 5:42 PM
  • shink test
sbc100 edited the summary of this revision. (Show Details)Dec 18 2017, 5:43 PM
sbc100 added a reviewer: ruiu.
sbc100 updated this revision to Diff 127445.Dec 18 2017, 5:44 PM
  • clang format
sbc100 edited the summary of this revision. (Show Details)Dec 18 2017, 5:45 PM
sbc100 added a reviewer: ncw.
sbc100 updated this revision to Diff 127450.Dec 18 2017, 5:54 PM
  • test with -r and without -r
ncw accepted this revision.EditedDec 19 2017, 3:23 AM

It's a start! (I guess this can be merged quickly, since it doesn't "do" much yet.)

For full support, I guess we're going to change things as follows?

  1. Scrap the --entry and --no-entry arguments, entrypoints are now specified via llvm global ctors instead.
  2. When not relocatable, synthesise a function that calls the InitFuncs
  3. Add a new argument --start-entry / --export-entry=NAME which determines whether the synthesised function is added as the start func or exported by name. (These are exclusive choices, the last-specified of --start-entry and --export-entry wins). The default could be either --start-entry or --export-entry=_start, I don't particularly mind.

Alternatively for (1), we could retain --entry / --no-entry, and simply have them specify a function that will be added to the very end of the InitFuncs. I suppose the use-case would be to maybe specify some sort of void _start_main() { exit(main()); } function? We can certainly provide a _start_main symbol like that in Musl, and allow users to choose whether or not main will be invoked by passing --entry=_start_main if they want it (not by default). Or we could be "clever" and see if the user has actually provided a function called "main", and change the default accordingly!

I've updated my Musl fork to expect these semantics, by changing it to do libc initialisation using a ctor function at highest priority:

This revision is now accepted and ready to land.Dec 19 2017, 3:23 AM

I like the idea of keeping the generated function (i.e. __wasm_call_ctors, or whatever we call it) separate from main(). Then its up the c library, or runtime to decide if they want to call those two things in the same call stack, or separately. For the emscripten use case I think we want to be able to fist call ctors().. then later on call main(). But with a more stand alone toolchain (such as one based your musl port), it could happen in the same call if we decide that makes sense.

This revision was automatically updated to reflect the committed changes.
ruiu added inline comments.Dec 27 2017, 1:41 AM

Can't you omit std::string?