This is an archive of the discontinued LLVM Phabricator instance.

[lld][WebAssembly] Add support for `--export-dynamic-symbol`
AbandonedPublic

Authored by sbc100 on Apr 25 2021, 5:19 PM.

Details

Reviewers
MaskRay
dschuff
Summary

Unlike the existing --export option this will not causes errors
or warnings if the specified symbol is not defined.

This is an existing flag from GNU ld and lld ELF backend.

See: https://github.com/emscripten-core/emscripten/issues/13736

Diff Detail

Event Timeline

sbc100 created this revision.Apr 25 2021, 5:19 PM
sbc100 requested review of this revision.Apr 25 2021, 5:19 PM
Herald added a project: Restricted Project. · View Herald TranscriptApr 25 2021, 5:19 PM
MaskRay added inline comments.Apr 25 2021, 6:43 PM
lld/wasm/Options.td
59

The ELF specific comment needs rework.

sbc100 updated this revision to Diff 340644.Apr 26 2021, 2:20 PM
  • rebase

LGTM modulo MaskRay's comment about the help text. Also I think @sunfish had a question earlier today that we didn't get to talk about.

sbc100 updated this revision to Diff 340658.Apr 26 2021, 2:50 PM

Feedback

MaskRay accepted this revision.Apr 26 2021, 2:53 PM
MaskRay added inline comments.
lld/wasm/Options.td
58

Drop period.

This revision is now accepted and ready to land.Apr 26 2021, 2:53 PM
sbc100 updated this revision to Diff 340664.Apr 26 2021, 3:01 PM
  • feedback

@sunfish any objections to landing this?

I'm a little confused by the name "export-dynamic-symbol". I understand it's an ELF flag, though it seems to have a slightly different meaning here. What would you think about adding a warning when using this flag is -experimental-pic isn't passed, similar to what we do with -shared?

I'm a little confused by the name "export-dynamic-symbol". I understand it's an ELF flag, though it seems to have a slightly different meaning here. What would you think about adding a warning when using this flag is -experimental-pic isn't passed, similar to what we do with -shared?

This flag, although it has dynamic its is name, does not imply PIC ABI stuff or imply -shared or -pie so I don't think it makes sense to link it to -experimental-pic. In works just like the existing --export flag but allows the symbol to be undefined. I plan to use this in emscripten when we are doing static linking.

sbc100 added a comment.EditedApr 28 2021, 11:43 AM

The existing --export flag, one could argue, already promotes symbols from the static world to the dyanmic (runtime) world, its just that it also implies --require-defined=foo. In fact one could potentially argue that --export should be deprecated in favor of --require-defined= + --export-dynamic-symbol= (although I'm not doing that).

My original version of this patch used the name --export-if-defined=.. if you feel strongly we could go back to that name instead, but I like sharing flags where possible rather than inventing new ones, and the meaning of this flag seems to match pretty well here.

Looking at the ld documentation for export-dynamic-symbol:

When creating a dynamically linked executable, symbols matching glob will be added to the dynamic symbol table.

We're applying this to statically linked executables too.

When creating a shared library, references to symbols matching glob will not be bound to the definitions within the shared library.

We don't have the semantics of allowing symbols to be preempted like ELF does.

I'm looking ahead to wasm-ld supporting new dynamic linking ABIs, which may be significantly different from ELF. So my preference here would be, if we have functionality which exactly matches ELF, it makes sense to reuse the ELF-specific names, otherwise we should use names which make sense for wasm on their own terms. Does that make sense?

Looking at the ld documentation for export-dynamic-symbol:

When creating a dynamically linked executable, symbols matching glob will be added to the dynamic symbol table.

We're applying this to statically linked executables too.

When creating a shared library, references to symbols matching glob will not be bound to the definitions within the shared library.

We don't have the semantics of allowing symbols to be preempted like ELF does.

I'm looking ahead to wasm-ld supporting new dynamic linking ABIs, which may be significantly different from ELF. So my preference here would be, if we have functionality which exactly matches ELF, it makes sense to reuse the ELF-specific names, otherwise we should use names which make sense for wasm on their own terms. Does that make sense?

So you think it would be preferable to go with --export-if-defined then, or something wasm specific?

So you think it would be preferable to go with --export-if-defined then, or something wasm specific?

Yes, --export-if-defined would be my preference here. "export" has a clear meaning in wasm terms, and we already have --export, so the meaning of --export-if-defined is clear.

sbc100 abandoned this revision.Apr 28 2021, 7:51 PM

Closing in favor of original change: https://reviews.llvm.org/D99887