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
WebAssembly depends on attributes.h which includes attributes.inc.
Unless cmake explicitly specifies this dependency, the .inc file
is sometimes generated after the build tries to use it.
Patch by Stella Stamenova
llvm-svn: 334581
This causes all symbols to be exported in the final wasm binary
even if they were not compiled with default visibility.
This feature is useful for the emscripten toolchain that has a
corresponding EXPORT_ALL feature which allows the JS code to
interact with all C function.
Differential Revision: https://reviews.llvm.org/D47806
llvm-svn: 334157
When a symbol is GC'd it can still be references by relocations
in the debug sections, but such symbols are not assigned virtual
addresses.
This change adds a new global data symbol which gets GC'd but
should still appears in the output debug info, albeit with a 0
address.
Fixes 37555
Differential Revision: https://reviews.llvm.org/D47238
llvm-svn: 333047
There are only certain relocation types that can exist in the
wasm code section and they are all LEB types. Remove the dead
code for handling the other (I32) reloc types.
Differential Revision: https://reviews.llvm.org/D47226
llvm-svn: 333030
* Gets function size field from right location
* Writes I32 values during compression
Patch by Yury Delendik
Differential Revision: https://reviews.llvm.org/D47204
llvm-svn: 333002
This change adds the ability for lld to remove LEB padding from
code section. This effectively shrinks the size of the resulting
binary in proportion to the number of code relocations.
Since there will be a performance cost this is currently only active for
-O1 and above. Some toolchains may instead want to perform this
compression as a post linker step (for example running a binary through
binaryen will automatically compress these values).
I imagine we might want to make this the default in the future.
Differential Revision: https://reviews.llvm.org/D46416
llvm-svn: 332783
Provide some free functions to reduce verbosity of endian-writing
a single value, and replace the endianness template parameter with
a field.
Part of PR37466.
Differential Revision: https://reviews.llvm.org/D47032
llvm-svn: 332757
Fixes: lld: warning: unexpected existing value for R_WEBASSEMBLY_FUNCTION_OFFSET_I32: existing=839 expected=838
The existing solution is trying to erroneously recover correct offset of
the function code from the body (which is not a function segment that
includes its size, locals, and code).
The D46763 is trying to maintain the offset of the function code
allowing properly calculate the new relocation entry.
Patch by Yury Delendik
Differential Revision: https://reviews.llvm.org/D46765
llvm-svn: 332412
The DEBUG() macro is very generic so it might clash with other projects.
The renaming was done as follows:
- git grep -l 'DEBUG' | xargs sed -i 's/\bDEBUG\s\?(/LLVM_DEBUG(/g'
- git diff -U0 master | ../clang/tools/clang-format/clang-format-diff.py -i -p1 -style LLVM
Differential Revision: https://reviews.llvm.org/D44977
llvm-svn: 332351
Since we a no longer using this function for the wasm start
section we don't actually care what its signature is.
Differential Revision: https://reviews.llvm.org/D46594
llvm-svn: 332308
Merging data segments produces smaller code sizes because each segment
has some boilerplate. Therefore, merging data segments is generally the
right approach, especially with wasm where binaries are typically
delivered over the network.
However, when analyzing wasm binaries, it can be helpful to get a
conservative picture of which functions are using which data
segments[0]. Perhaps there is a large data segment that you didn't
expect to be included in the wasm, introduced by some library you're
using, and you'd like to know which library it was. In this scenario,
merging data segments only makes the analysis worse.
Alternatively, perhaps you will remove some dead functions by-hand[1]
that can't be statically proven dead by the compiler or lld, and
removing these functions might make some data garbage collect-able, and
you'd like to run `--gc-sections` again so that this now-unused data can
be collected. If the segments were originally merged, then a single use
of the merged data segment will entrench all of the data.
[0] https://github.com/rustwasm/twiggy
[1] https://github.com/fitzgen/wasm-snip
Patch by Nick Fitzgerald!
Differential Revision: https://reviews.llvm.org/D46417
llvm-svn: 332013
This is most useful when using lld-link on a non-Win host (but it might become
useful on Windows too if lld also grows a fansi-escape-codes flag).
Also make the help for --color-diagnostic mention the valid values in ELF and
wasm, and print the flag name with two dashes in diags, since the one-dash form
is seen as a list of many one-letter flags in some contexts.
https://reviews.llvm.org/D46693
llvm-svn: 332012
Also:
- Reduce the error to a warning so that debug and release
versions can still link the same inputs.
- Add another check to verify the input LEB is padded to 5 bytes
Differential Revision: https://reviews.llvm.org/D46479
llvm-svn: 331571
Specifically add support for custom sections that contain
relocations, and for the two new relocation types needed
by DWARF sections.
See: https://reviews.llvm.org/D44184
Patch by Yury Delendik!
Differential Revision: https://reviews.llvm.org/D44184
llvm-svn: 331566
Enables cleaning up confusion between which name variables are mangled
and which are unmangled, and --print-gc-sections then excersises and
tests that.
Differential Revision: https://reviews.llvm.org/D44440
llvm-svn: 330449
Relocation addends can be negative so should be written as
signed LEBs. This bug meant that writing value between 64
and 128 would be incorrectly interpreted as negative by the
object file readers.
Differential Revision: https://reviews.llvm.org/D45825
llvm-svn: 330374
Summary:
The content of custome sections no longer includes the
name itself.
See: https://reviews.llvm.org/D45579
Subscribers: jfb, dschuff, jgravelle-google, aheejin, sunfish, llvm-commits
Differential Revision: https://reviews.llvm.org/D45580
llvm-svn: 329948
Copy user-defined custom sections into the output, concatenating
sections with the same name.
Differential Revision: https://reviews.llvm.org/D45340
llvm-svn: 329717
Since InputGlobal makes a copy of a given object, we can use a temporary
object allocated on the stack here.
Differential Revision: https://reviews.llvm.org/D43924
llvm-svn: 329337
This enables callback-style programming where the JavaScript environment
can call back into the Wasm environment using a function pointer
received from the module.
Differential Revision: https://reviews.llvm.org/D44427
llvm-svn: 328643
This reduces the number of lookups to one per COMDAT group, rather than
one per symbol in a COMDAT group.
Differential Revision: https://reviews.llvm.org/D44344
llvm-svn: 327523
Previously, Config->InitialMemory/MaxMemory were hooked up to some
commandline args but had no effect at all.
Differential Revision: https://reviews.llvm.org/D44393
llvm-svn: 327508
This fixes issues found on the wasm waterfall related to relocations
with addends. Undefined symbols, even those with addends should
always have a provisional value of zero. At least this is what llvm
emits (and I believe this is true for ELF too).
Differential Revision: https://reviews.llvm.org/D44451
llvm-svn: 327468
Previously, Config->Demangle was uninitialised (not hooked up to
commandline handling)
Differential Revision: https://reviews.llvm.org/D44301
llvm-svn: 327390
Verify that the location where a relocation is about the be
applied contains the expected existing value.
This is essentially a sanity check to catch bugs in the compiler
and the linker.
Differential Revision: https://reviews.llvm.org/D44349
llvm-svn: 327325
This bug was found by accident while trying to expand out testcases
for imported symbols, and is covered by the additional test case.
Differential Revision: https://reviews.llvm.org/D44331
llvm-svn: 327290
This matches the existing ordering that's been there for globals
for a while (__stack_pointer coming first).
Differential Revision: https://reviews.llvm.org/D44333
llvm-svn: 327286
toString(T) is a stringize function for an object of type T. Each type
that has that function defined should know how to stringize itself, and
there should be one string representation of an object. Passing a
"supplemental" argument to toString() breaks that princple. We shouldn't
add a second parameter to that function.
Differential Revision: https://reviews.llvm.org/D44323
llvm-svn: 327182
This error case is described in Linking.md. The operand for call requires
generation of a synthetic stub.
Differential Revision: https://reviews.llvm.org/D44028
llvm-svn: 327151
Previously we created __wasm_call_ctors with null InputFunction, and
added the InputFunction later. Now we create the SyntheticFunction with
null body, and set the body later.
Differential Revision: https://reviews.llvm.org/D44206
llvm-svn: 327149
When a symbol is exported via --export=foo but --allow-undefined
is also specified, the symbol is now allowed to be undefined.
Previously we were special casing such symbols.
This combinations of behavior is exactly what emescripten
requires. Although we are trying hard not to allow emscripten
specific features in lld, this one makes sense.
Enforce this behavior by added this case to test/wasm/undefined.ll.
Differential Revision: https://reviews.llvm.org/D44237
llvm-svn: 326976
This avoids the Writer unnecessarily having a member to retain ownership
of the function body.
Differential Revision: https://reviews.llvm.org/D43933
llvm-svn: 326580
Let X and Y be types. Previously, functions F(X, Y) and G(Y, X) had
the same hash value because their hash values are computed as follows:
hash(F) = hash(X) + hash(Y)
hash(G) = hash(Y) + hash(X)
This patch fixes the issue by using hash_combine.
Differential Revision: https://reviews.llvm.org/D43856
llvm-svn: 326336
This patch simplifies initializeSymbols. Since that function is called
at the tail context of ObjFile::parse, and the function is called only
once from that function, that's effectively just a continuation of
ObjFile::parse. So this patch merge it with ObjFile::parse.
Differential Revision: https://reviews.llvm.org/D43848
llvm-svn: 326296
The problem I want to address now is that chunks have too many data
members for "offsets", and their origins are not well defined.
For example, InputSegment has OutputSegmentOffset, but it's base class
also has OutputOffset. That's very confusing.
Differential Revision: https://reviews.llvm.org/D43726
llvm-svn: 326291
These output section names are ELF-specific. We shouldn't have this rule
for WebAssembly.
Differential Revision: https://reviews.llvm.org/D43712
llvm-svn: 326289
SubSection inherited from SyntheticSection, and SyntheticSection inherits
from OutputSection, so SubSection was an OutputSection. But that's wrong
because SubSection is not actually a WebAssembly output section.
It shares some functionalities with OutputSection, but overall it's very
different.
This patch removes that inheritance.
Differential Revision: https://reviews.llvm.org/D43719
llvm-svn: 326286
FileOutputBuffer automatically removes an existing file, so we don't
need to do that. Actually doing that is discouraged because when the
linker fails to create an output for some reason after instantiating
FileOutputBufffer, FileOutputBuffer removes a temporary file and don't
touch an existing file. That's an desired behavior from the user's
point of view.
(Internally, FileOutputBuffer writes its contents to a temporary file
and then rename it over to an existing file on commit()).
Differential Revision: https://reviews.llvm.org/D43728
llvm-svn: 326281
Looks like these accessor functions are a bit overly defensive, and
due to the amount of code, that part isn't easy to read. We have
code to log translation results in writeTo and writeRelocations, so
I don't think we need to log it again in these functions.
I think the new function is much easier to understand.
Differential Revision: https://reviews.llvm.org/D43713
llvm-svn: 326277
Instead of {Function,Global,Data}Symbol, use Defined{Function,Global,Data}
because undefined symbol should never reach this function.
Differential Revision: https://reviews.llvm.org/D43710
llvm-svn: 326275
I think calling reserve() for each object file is too many and isn't useful.
We can add reserve() later. By default, we shouldn't add reserve() to a lot
of places.
Differential Revision: https://reviews.llvm.org/D43722
llvm-svn: 326273
Previously, one function adds all types of undefined symbols. That
doesn't fit to the wasm's undefined symbol semantics well because
different types of undefined symbols are very different in wasm.
As a result, separate control flows merge in this addUndefined function
and then separate again for each type. That wasn't easy to read.
This patch separates the function into three functions. Now it is pretty
clear what we are doing for each undefined symbol type.
Differential Revision: https://reviews.llvm.org/D43697
llvm-svn: 326271
This means we don't need to write the linking metadata section
at all for executable (non-relocatable) output.
Differential Revision: https://reviews.llvm.org/D42869
llvm-svn: 326268
lld uses an arena allocator to one of allocations
like these can just use make<>.
Differential Revision: https://reviews.llvm.org/D43587
llvm-svn: 325706
Purely a rename in preparation for adding new global symbol type.
We want to use GlobalSymbol to represent real wasm globals and
DataSymbol for pointers to things in linear memory (what ELF would
call STT_OBJECT).
This reduces the size the patch to add the explicit symbol table
which is coming soon!
Differential Revision: https://reviews.llvm.org/D43476
llvm-svn: 325645
The profailing style in lld seem to be to not include such empty lines.
Clang-tidy/clang-format seem to handle this just fine.
Differential Revision: https://reviews.llvm.org/D43528
llvm-svn: 325629
I think if statements that end with return is easier to read than
cascaded if-else-if-else-if statements because it makes clear that
execution of a function terminates there. This patch also adds more
blank lines to separate code blocks to meaningful pieces.
Differential Revision: https://reviews.llvm.org/D43517
llvm-svn: 325625
This header used to be needed here for the `OutRelocation` struct
but that no longer exists.
Differential Revision: https://reviews.llvm.org/D43516
llvm-svn: 325608
Instead include InputFuction and InputSegment directly
in the subclasses that use them (DefinedFunction and
DefinedGlobal).
Differential Revision: https://reviews.llvm.org/D43493
llvm-svn: 325603
This patch removes `OutRelocations` vector from the InputChunk and
directly consume `Relocations` vector instead. This should make the linker
faster because we don't create a temporary data structure, and it matches
the lld's design principle that we don't create temporary data structures
for object files but instead directly consume mmap'ed data whenever possible.
Differential Revision: https://reviews.llvm.org/D43491
llvm-svn: 325549
We already have isa<> for this, and these methods were simply
duplicating those redundantly.
Differential Revision: https://reviews.llvm.org/D43422
llvm-svn: 325418
Summary:
- Makes code more in line with LLVM style (e.g. const char * -> StringRef)
- Do not use formatv since we can construct message just by `+`
- Replace some odd types such as `const StringRef` with more common type
- Do not use default arguments if they are not necessary
Reviewers: sbc100
Subscribers: jfb, aheejin, llvm-commits, sunfish
Differential Revision: https://reviews.llvm.org/D43403
llvm-svn: 325383
This bug effected undefined symbols that were resolved by
existing defined symbols. We were skipping the signature
check in this case.
Differential Revision: https://reviews.llvm.org/D43399
llvm-svn: 325376
This was causing GCC builds with fail with:
Symbols.h:240:3: error: static assertion failed: Symbol types must be
trivially destructible
static_assert(std::is_trivially_destructible<T>(
The reason this is a gcc-only failure is that OptionalStorage has
as specialization for POD types that isn't built under GCC.
Differential Revision: https://reviews.llvm.org/D43317
llvm-svn: 325185
This brings wasm into line with ELF and COFF in terms of
symbol types are represented.
Differential Revision: https://reviews.llvm.org/D43112
llvm-svn: 325150
SetVector guarantees ordering, so with that we can get a deterministic
output for error messages.
Differential Revision: https://reviews.llvm.org/D43254
llvm-svn: 325064
It seems redundant to store this information twice. None of the
locations where this bit is checked care about the distinction.
Differential Revision: https://reviews.llvm.org/D43250
llvm-svn: 325046
These were duplicating (incorrectly) some of the logic for
handling conflicts, but since they are only ever added right
at the start we can assume no existing symbols.
Also rename these methods for clarity.
Differential Revision: https://reviews.llvm.org/D43252
llvm-svn: 325045
This is similar to _end (See https://linux.die.net/man/3/edata for more)
but using our own unique name since our use cases will most likely be
different and we want to keep our options open WRT to memory layout.
This change will allow is to remove the DataSize from the linking
metadata section which is currently being used by emscripten to derive
the end of the data.
Differential Revision: https://reviews.llvm.org/D42867
llvm-svn: 324443
Group all synthetic symbols in the in single struct to match
the ELF linker.
This change is part of a larger change to add more linker
symbols such as `_end` and `_edata`.
Differential Revision: https://reviews.llvm.org/D42866
llvm-svn: 324157
Don't include type signatures that are not referenced by
some relocation.
We don't include this in the -gc-sections settings since
we are always building the type section from scratch,
just like we do the table elements.
In the future we might want to unify the relocation
processing which is currently done once for gc-sections
and then again for building the sympathetic type and
table sections.
Differential Revision: https://reviews.llvm.org/D42747
llvm-svn: 323931
In this initial version we only GC symbols with `hidden` visibility since
other symbols we export to the embedder.
We could potentially modify this the future and only use symbols
explicitly passed via `--export` as GC roots.
This version of the code only does GC of data and code. GC for the
types section is coming soon.
Differential Revision: https://reviews.llvm.org/D42511
llvm-svn: 323842
Summary:
Rather than explicit Function or InputSegment points store a
pointer to the base class (InputChunk) and use llvm dynamic
casts when we need a subtype.
This change is useful for add the upcoming gc-section support
wants to deal with all input chunks.
Subscribers: aheejin, llvm-commits
Differential Revision: https://reviews.llvm.org/D42625
llvm-svn: 323621
Previously, we were ensuring that the "output index" for
InputFunctions was unique across all symbols that referenced
a function body, but allowing the same function body to have
multiple table indexes.
Now, we use the same mechanism for table indexes as we already
do for output indexes, ensuring that each InputFunction is only
placed in the table once.
This makes the LLD output table denser and smaller, but should
not change the behaviour.
Note that we still need the `Symbol::TableIndex` member, to
store the table index for function Symbols that don't have an
InputFunction, i.e. for address-taken imports.
Patch by Nicholas Wilson!
Differential Revision: https://reviews.llvm.org/D42476
llvm-svn: 323379
Heejin Ahn