This is an archive of the discontinued LLVM Phabricator instance.

[WebAssembly] Remove --emit-relocs
ClosedPublic

Authored by sbc100 on Jan 19 2018, 3:23 PM.

Details

Summary

This was added to mimick ELF, but maintaining it has cost
and we currently don't have any use for it outside of the
test code.

Event Timeline

sbc100 created this revision.Jan 19 2018, 3:23 PM
sbc100 updated this revision to Diff 130708.Jan 19 2018, 3:28 PM
  • remove condition
  • more tests
ncw accepted this revision.Jan 19 2018, 5:07 PM

@ruiu some background. We've been discussing whether there should be a genuine difference between relocatable and non-relocatable Wasm objects. Or to put it another way, if you run LLD on a single object file, should anything really change? Maybe a few bits and pieces in the headers, but the actual body should be basically "stable", maybe stripping some dead functions,.

At the moment, --relocatable output really is quite different to normal output, in that it creates Wasm imports+exports for everything, whereas normal LLD output doesn't export local functions for example.

Hence --emit-relocs doesn't really work, you can't just "emit the relocs", since without having the imports/exports there's nothing to relocate against. You can't emit the relocs unless you're writing out a whole different object file.

This revision is now accepted and ready to land.Jan 19 2018, 5:07 PM
ruiu added a comment.Jan 19 2018, 5:19 PM

I'm not sure if I understand it correctly, so let me write down a few facts I believe true.

  • --emit-relocs is not the same as -r. IIUC, they were created for pretty different purposes. --emit-relocs is to let the linker to emit the regular linked dso/executables along with relocation information (which is usually consumed by the linker and then removed from output), so that some post-processing tool can analyze the binary to do whatever they want to do. So, relocations in --emit-relocs is just "informative". OTOH, -r lets the linker to create a re-linkable, regular object files. With that feature, you can combine multiple .o files into a single .o.
  • The output of -r is naturally quite different from the normal output. That's a natural consequence that the normal output is assumed to be consumed by the dynamic linker while the -r output is consumed by the static linker. So the difference is as large as the .o file and the .exe file, and that's not odd.
  • I don't know why you wanted --emit-relocs at this point -- lld have that option because, IIRC, the Linux kernel needs it to do some tricky thing. Normally, you don't need that option.

Hope this helps.

In D42324#982698, @ruiu wrote:

I'm not sure if I understand it correctly, so let me write down a few facts I believe true.

  • --emit-relocs is not the same as -r. IIUC, they were created for pretty different purposes. --emit-relocs is to let the linker to emit the regular linked dso/executables along with relocation information (which is usually consumed by the linker and then removed from output), so that some post-processing tool can analyze the binary to do whatever they want to do. So, relocations in --emit-relocs is just "informative". OTOH, -r lets the linker to create a re-linkable, regular object files. With that feature, you can combine multiple .o files into a single .o.
  • The output of -r is naturally quite different from the normal output. That's a natural consequence that the normal output is assumed to be consumed by the dynamic linker while the -r output is consumed by the static linker. So the difference is as large as the .o file and the .exe file, and that's not odd.
  • I don't know why you wanted --emit-relocs at this point -- lld have that option because, IIRC, the Linux kernel needs it to do some tricky thing. Normally, you don't need that option.

Hope this helps.

That all sounds right to me.

In short, we probably never should have add --emit-relocs to the wasm linker in the first place. If we ever find a need for it we can add it back.

And yes, our .o files and .wasm files do have a fair few differences.

ping @ruiu (not sure if I should be waiting on your lg here or not)

ruiu accepted this revision.Jan 22 2018, 12:36 PM

LGTM

This revision was automatically updated to reflect the committed changes.