This is an archive of the discontinued LLVM Phabricator instance.

[WebAssembly] Initial support for shared objects (-shared)
ClosedPublic

Authored by sbc100 on Nov 7 2018, 6:04 PM.

Event Timeline

sbc100 created this revision.Nov 7 2018, 6:04 PM
sbc100 updated this revision to Diff 173109.Nov 7 2018, 6:09 PM
  • add assert
  • clang format
sbc100 updated this revision to Diff 173110.Nov 7 2018, 6:13 PM

fix test

dschuff added inline comments.Nov 8 2018, 10:49 AM
docs/WebAssembly.rst
34

not related to this CL, but we should probably update the list of missing features.

sbc100 added inline comments.Nov 8 2018, 11:19 AM
docs/WebAssembly.rst
34

Yes, I did that a while back but had to revert because of some sphinx issue: https://reviews.llvm.org/D52048

Will try again,

ruiu added a comment.Nov 11 2018, 10:04 PM

Can you add this to ReleaseNotes?

wasm/Driver.cpp
403–404

Sort alphabetically.

489

Can you add a comment for this code block so that it is clear what we are doing if Config->Pic?

sbc100 updated this revision to Diff 173795.Nov 12 2018, 5:30 PM
sbc100 marked an inline comment as done.
  • feedback
  • add comment
sbc100 marked an inline comment as done.Nov 12 2018, 5:30 PM
ruiu added inline comments.Nov 12 2018, 10:29 PM
wasm/Driver.cpp
397

This may be a silly question, but in wasm, what is the notion of position-independent executable? Are executable expected to be loaded at a fixed address by default, and you can opt out with -pie? The notion of PIE is dependent on the memory layout of the physical machine, and that's quite different from wasm's memory model.

sbc100 added inline comments.Nov 13 2018, 8:49 AM
wasm/Driver.cpp
397

The meaning of -fPIC/-fpie is a little different for wasm. Since the code its JITd rather than mmaped, all the code is position independent by defintion. However there are two things these flags are needed for:

  1. For -fPIC code the location of global data is not known at link time, so global data accesses are offset from the __memory_base import.
  2. All indirect function calls need to go via the indirect function table, but for -fPIE the region of the table we are using is not known until runtime so we need to be offset all table indexes by __table_base.

This means that code compiled with -fPIC pays a slight performance cost for accessing global data and calling non-hidden function.

In these respect -shared and -fpie produce very similar results (both these options set Config->Pie which triggers most of this behaviour).

For an executable compiled without -fpie the location of memory_base and table_base is fixed at link time so slightly more efficient even when given code compiled with -fPIC.

sbc100 updated this revision to Diff 173898.Nov 13 2018, 11:54 AM
  • fix global base
sunfish added inline comments.Nov 13 2018, 12:39 PM
docs/ReleaseNotes.rst
72 ↗(On Diff #173898)

We should make it clear that the ABI is not stable. In fact, it may change significantly in the future if we move to two-level namespacing and/or making use of ES6 module integration.

sbc100 updated this revision to Diff 173938.Nov 13 2018, 2:11 PM
  • add note about current status
sbc100 updated this revision to Diff 173962.Nov 13 2018, 4:35 PM
  • don't require entry point for shared libraries
sbc100 updated this revision to Diff 173964.Nov 13 2018, 4:42 PM
  • Always import the table with -shared
dschuff added inline comments.Nov 13 2018, 5:39 PM
wasm/Driver.cpp
465

incompatible

491

remove "to"

492

"static data and function table" is the opposite of the order that __table_base and __memory base have above.

wasm/OutputSections.cpp
141

Can this be a report_fatal_error or something even more friendly instead of an assert, since this could happen as the result of user input?

wasm/Writer.cpp
714

shouldn't this go after the data section since it's a custom section?

sbc100 updated this revision to Diff 173975.Nov 13 2018, 6:27 PM
  • feedback
wasm/OutputSections.cpp
141

This should not be able to occur due to user input since we only ever create a single segment in Writer.cpp if Config->Pic, so this is really just an internal check.

wasm/Writer.cpp
714

No, this section actually always comes first in the entire file to make dll's easy to detect.

The "spec" says: The "dylink" section should be the very first section in the module; this allows detection of whether a binary is a dynamic library without having to scan the entire contents.

sbc100 marked 3 inline comments as done.Nov 13 2018, 6:28 PM
dschuff accepted this revision.Nov 14 2018, 10:17 AM
This revision is now accepted and ready to land.Nov 14 2018, 10:17 AM
sbc100 updated this revision to Diff 174067.Nov 14 2018, 11:02 AM
  • update test
This revision was automatically updated to reflect the committed changes.
This revision was automatically updated to reflect the committed changes.