This is an archive of the discontinued LLVM Phabricator instance.

Implement __attribute__((import_module("foo")))
ClosedPublic

Authored by sunfish on Jan 24 2018, 9:03 PM.

Details

Summary

This creates an attribute for specifying an explicit import module name for a function declaration. It also renames the default module import name from "env" to "__linker_resolve", which should be less likely to collide with other things, though I'm open to other suggestions.

The expectation is that it's the linker's job to resolve symbols that have the default module name, so that they're either linked to a definition in the same resulting module, or to a definition in a separate module with two-level namespacing. Modules with non-default names should be left alone.

It only applies to functions for now; we can generalize it for global variables later if needed.

Diff Detail

Repository
rL LLVM

Event Timeline

sunfish created this revision.Jan 24 2018, 9:03 PM
ncw added a comment.Jan 24 2018, 10:25 PM

Renaming the default module to __linker_resolve seems fine.

However, D42495 currently in progress involves changing the way symbols are read from a Wasm object file. There's now going to be an explicit symbol table, so the linker won't resolve all imports, but only imports which correspond to symbols. I guess we could have WasmObjectWriter skip any imports that aren't in the __linker_resolve module, and not create symbols for them; and the linker could merge together imports from the object files that come from other modules...

Is there any current use-case for allowing the module to be customised?

pepyakin added inline comments.
include/llvm/MC/MCSymbolWasm.h
34 ↗(On Diff #131388)

I guess there should be "__linker_resolve"

aaron.ballman requested changes to this revision.Jan 25 2018, 5:35 AM
aaron.ballman added a reviewer: aaron.ballman.
aaron.ballman added a subscriber: aaron.ballman.

You're missing a lot of test cases for the semantic checks of the attribute in Clang. There should be a Sema test that ensures things like the attribute subject, its argument count and types, etc.

tools/clang/include/clang/Basic/Attr.td
1367 ↗(On Diff #131388)

No new, undocumented attributes, please.

tools/clang/lib/CodeGen/TargetInfo.cpp
738 ↗(On Diff #131388)

const auto * -- Also, can D really be null?

739 ↗(On Diff #131388)

const auto *

tools/clang/lib/Sema/SemaDeclAttr.cpp
5437 ↗(On Diff #131388)

This should be specified by the Subjects list in Attr.td.

5445 ↗(On Diff #131388)

Is this function really an alias?

In D42520#987422, @ncw wrote:

However, D42495 currently in progress involves changing the way symbols are read from a Wasm object file. There's now going to be an explicit symbol table, so the linker won't resolve all imports, but only imports which correspond to symbols. I guess we could have WasmObjectWriter skip any imports that aren't in the __linker_resolve module, and not create symbols for them; and the linker could merge together imports from the object files that come from other modules...

I'm behind on the new symbol table structure. What you propose here makes sense. In fact, in that case we can probably eliminate the "__linker_resolve" special name, and just have a bool in MCSymbolWasm which indicates whether a symbol should be omitted from the symbol table.

Is there any current use-case for allowing the module to be customised?

Linking with ES modules. A tool could generate a C/C++ header file which declares functions provided by the ES module, which could use this attribute to set up the module name.

And actually, thinking about both of these together, I think we should take this attribute a step further and include the fieldname, as in: __attribute__((import("modulename", "fieldname"))) or so, because you may want to use a different fieldname than the C++ declaration name. I'll rework the patch along these lines.

ncw added a comment.Jan 25 2018, 8:34 AM

Linking with ES modules. A tool could generate a C/C++ header file which declares functions provided by the ES module, which could use this attribute to set up the module name.

And actually, thinking about both of these together, I think we should take this attribute a step further and include the fieldname, as in: __attribute__((import("modulename", "fieldname"))) or so, because you may want to use a different fieldname than the C++ declaration name. I'll rework the patch along these lines.

That would make sense then. I don't suppose that there's any crossover with C++ modules is there?

In D42520#988036, @ncw wrote:

I don't suppose that there's any crossover with C++ modules is there?

Some tools may want to have a convention where ES modules are mapped to C++ modules, but that's not the only way things could be set up. I'm thinking of this attribute as a mechanism on top of which a variety of policies could be built.

In general, this seems like a good idea.

include/llvm/MC/MCSymbolWasm.h
39 ↗(On Diff #131388)

To keep this change focused, perhaps this rename can be done separately.

This would have several advantages:

  1. Separate the addition of this new attribute from the bike-shedding around this default name
  2. Allow with change to land without break lld (or requiring any lld change at all)
  3. Possible avoid churns since we are looking to landing the symbol table change soon anyway which might eliminate this
  4. Keep this change small

If we are going to bikeshed a new name here, I would go for something a little shorter, but I like the __ prefix. Perhaps just __extern?

sunfish updated this revision to Diff 132910.Feb 5 2018, 4:41 PM
sunfish removed a reviewer: aaron.ballman.
  • Go back to using "env" for now, so that this is independent of the symbol-table changes and avoids bike-shedding discussions for now.
  • Split the clang changes out into a separate patch, which I'll post separately.

I believe this addresses all the comments so far on the LLVM side; I'll address the clang comments on the clang patch.

@sbc100 I've updated the patch to leave the "env" namespace in place. Do you think this is ready to land now?

sbc100 accepted this revision.Feb 9 2018, 1:48 PM

Great!

Might want to update the commit message before submitting.

This revision is now accepted and ready to land.Feb 9 2018, 1:48 PM
This revision was automatically updated to reflect the committed changes.