wasm-linker: feature compatibility validation #13287
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
kubkon
reviewed
Oct 24, 2022
Verifies disallowed and used/required features. After verifying, all errors will be emit to notify the user about incompatible features. When the user did not define any featureset, we infer the features from the linked objects instead.
When the result is not being stripped, we emit the `target_features` section based on all the used features. This includes features inferred from linked object files. Considering we know all possible features upfront, we can use an array and therefore do not have to dynamically allocate memory. Using this trick we can also easily order all features based the same ordering as found in `std.Target.wasm` which is the same ordering used by LLVM and the like.
When an object file or binary contains the target_features section we can now parse and then dump its contents in string format so we can use them in our linker tests to verify the features section.
Adds a test for inferring features based on a different object file. Also provides a test case where cpu features are explicitly set on a library where the end result will output said target features.
The list of features a Wasm object/binary file can emit can differ from the list of cpu features. The reason for this is because the "target_features" section also contains linker features. An example of this is the "shared-mem" feature, which is a feature for the linker and not that of the cpu target as defined by LLVM.
Considering all possible features are known by the linker during compile-time, we can create arrays on the stack instead of dynamically allocating hash maps. We use a simple bitset to determine whether a feature is enabled or not, and from which object file it originates. This allows us to make feature validation slightly faster and use less runtime memory. In the future this could be enhanced further by having a single array instead with a more sophisticated bitset.
Luukdegram
force-pushed
the
wasm-features
branch
from
3f70f67
to
c0710b0
Compare
kubkon
approved these changes
Oct 25, 2022
There was a problem hiding this comment.
Looks great! I know that it might look like the mechanism for extracting the features is really terse and messy, but it could easily be pulled into a couple of inlined helper function calls down the line and it would make potential contributors none the wiser. Awesome work!
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Wasm object files and binaries can contain an optional section called the
target_featuressection. This section describes features that are used, required, or disallowed. This PR implements the validation of each linked object file and its features to ensure the generated binary is compatible. For example, when object A uses the feature 'atomics' but object B disallows the feature 'atomics' it's a linker error. Only when the user has specified features or any of the linked object files do, will we emit this section. As it's optional, it's omitted when providing the-fstripflag. When the user did not specify any features, we instead infer them from any of the linked object files. For the curious reader, more information can be found at: https://github.com/WebAssembly/tool-conventions/blob/main/Linking.md#target-features-section