Summary:
At the beginning of `assignIndexes() function, when `FunctionIndex` and
`GlobalIndex` variables are created, `InputFunctions` and `InputGlobals`
vectors are guaranteed to be empty, because those vectors are only
populated in `assignIndexes()` function. Current code looks like they
are nonempty, so this patch deletes them for better readability.
Reviewers: sbc100
Subscribers: dschuff, jgravelle-google, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D54687
llvm-svn: 347272
`--no-demangle` now also applies to the name section. This change
was motivated by the rust team that have a slightly different name
mangling scheme to the standard C++ itanium one and prefer to do their
de-mangling as a post-link setp.
Patch by Alex Crichton!
Differential Revision: https://reviews.llvm.org/D54279
llvm-svn: 346516
Used for WebAssembly threads proposal. Add a flag --shared-memory
which sets the IS_SHARED bit in WasmLimits
Differential Revision: https://reviews.llvm.org/D54130
llvm-svn: 346248
Summary: Before, OptTable::PrintHelp append "[options] <inputs>" to its parameter `Help`. It is more flexible to change its semantic to `Usage` and let user customize the usage line.
Reviewers: rupprecht, ruiu, espindola
Reviewed By: rupprecht
Subscribers: emaste, sbc100, arichardson, aheejin, llvm-commits
Differential Revision: https://reviews.llvm.org/D53054
llvm-svn: 344099
With LTO when and undefined function (with a known signature)
in replaced by a defined bitcode function we were loosing the
signature information (since bitcode functions don't have
signatures).
With this change we preserve the original signature from the
undefined function and verify that the post LTO compiled
function has the correct signature.
This change improves the error handling in the case where
there is a signature mismatch with a function defined in
a bitcode file.
Differential Revision: https://reviews.llvm.org/D50721
llvm-svn: 343340
In a very recent change I introduced a --no-export-default flag
but after conferring with others it seems that this feature already
exists in gnu GNU ld and lld in the form the --export-dynamic flag
which is off by default.
This change replaces export-default with export-dynamic and also
changes the default to match the traditional linker behaviour.
Now, by default, only the entry point is exported. If other symbols
are required by the embedder then --export-dynamic or --export can
be used to export all visibility hidden symbols or individual
symbols respectively.
This change touches a lot of tests that were relying on symbols
being exported by default. I imagine it will also effect many
users but do think the change is worth it match of the traditional
behaviour and flag names.
Differential Revision: https://reviews.llvm.org/D52587
llvm-svn: 343265
These option control weather or not symbols marked as visibility
default are exported in the output binary.
By default this is true, but emscripten prefers to control the
exported symbol list explicitly at link time and ignore the
symbol attributes.
Differential Revision: https://reviews.llvm.org/D52003
llvm-svn: 343034
Summary:
Currently we are pointing all debug information that refer removed function code
to the beginning of the code section (offset = 0). A debugger may want to
resolve code offset to the debug information, which will collide with offsets
of the live functions.
Moving offsets of dead functions outside code section range.
Reviewers: sbc100
Reviewed By: sbc100
Subscribers: dblaikie, ruiu, alexcrichton, dschuff, aprantl, jgravelle-google, aheejin, sunfish, JDevlieghere, llvm-commits
Differential Revision: https://reviews.llvm.org/D49446
llvm-svn: 342930
This is a minor follow-up to https://reviews.llvm.org/D49189. On Windows, lld
used to print "lld-link.exe: error: ...". Now it just prints "lld-link: error:
...". This matches what link.exe does (it prints "LINK : ...") and makes lld's
output less dependent on the host system.
https://reviews.llvm.org/D51133
llvm-svn: 340487
LEB compression breaks debug info so we don't want to enable
it by default, even at high optimization levels.
Differential Revision: https://reviews.llvm.org/D50729
llvm-svn: 340073
--export now implies --undefined
This is really a requirement from emscripten but I think it
makes sense in general too.
Differential Revision: https://reviews.llvm.org/D50287
llvm-svn: 339047
This matches the behavior of the ELF linker where -u/--undefined
means symbols will get pulled in from archives but won't result
in link error if they are missing.
Also, don't actually great symbol table entries for the undefined
symbols, again matching more closely the ELF linker.
This also results in simplification of the code.
Differential Revision: https://reviews.llvm.org/D50279
llvm-svn: 338938
lld currently prepends the absolute path to itself to every diagnostic it
emits. This path can be longer than the diagnostic, and makes the actual error
message hard to read.
There isn't a good reason for printing this path: if you want to know which lld
you're running, pass -v to clang – chances are that if you're unsure of this,
you're not only unsure when it errors out. Some people want an indication that
the diagnostic is from the linker though, so instead print just the basename of
the linker's path.
Before:
```
$ out/bin/clang -target x86_64-unknown-linux -x c++ /dev/null -fuse-ld=lld
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crt1.o: No such file or directory
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crti.o: No such file or directory
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crtbegin.o: No such file or directory
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lgcc
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lgcc_s
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lc
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lgcc
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: unable to find library -lgcc_s
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crtend.o: No such file or directory
/Users/thakis/src/llvm-mono/out/bin/ld.lld: error: cannot open crtn.o: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
After:
```
$ out/bin/clang -target x86_64-unknown-linux -x c++ /dev/null -fuse-ld=lld
ld.lld: error: cannot open crt1.o: No such file or directory
ld.lld: error: cannot open crti.o: No such file or directory
ld.lld: error: cannot open crtbegin.o: No such file or directory
ld.lld: error: unable to find library -lgcc
ld.lld: error: unable to find library -lgcc_s
ld.lld: error: unable to find library -lc
ld.lld: error: unable to find library -lgcc
ld.lld: error: unable to find library -lgcc_s
ld.lld: error: cannot open crtend.o: No such file or directory
ld.lld: error: cannot open crtn.o: No such file or directory
clang: error: linker command failed with exit code 1 (use -v to see invocation)
```
https://reviews.llvm.org/D49189
llvm-svn: 337634
This change effects the behavior of --export-all. Previously
--export-all would only effect symbols that survived GC. Now
--export-all will prevent any non-local symbols from being GCed.
Differential Revision: https://reviews.llvm.org/D48673
llvm-svn: 335878
Function symbols that come from bitcode have not signatures.
After LTO when the real symbols are read in we need to make
sure that we set the signature on the existing symbol.
the signature-less undefined functions.
Differential Revision: https://reviews.llvm.org/D48693
llvm-svn: 335875
This caused a lot of issues on the WebAssembly waterfall.
In particular, until with the signature of `main`. We
probably want a better solution for main before we re-land.
Reverts rL335192
llvm-svn: 335355
During symbol resolution, emit warnings for function signature
mismatches. During GC, if any mismatched symbol is marked as live
then generate an error.
This means that we only error out if the mismatch is written to the
final output. i.e. if we would generate an invalid wasm file.
Differential Revision: https://reviews.llvm.org/D48394
llvm-svn: 335192
Thomas Lively