This reverts commit 4e4ee1c507e2707bb3c208e1e1b6551c3015cbf5.
This is failing due to some code that isn't built on MSVC
so I didn't catch. Not immediately obvious how to fix this
at first glance, so I'm reverting for now.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315536 91177308-0d34-0410-b5e6-96231b3b80d8
There's a lot of misuse of Twine scattered around LLVM. This
ranges in severity from benign (returning a Twine from a function
by value that is just a string literal) to pretty sketchy (storing
a Twine by value in a class). While there are some uses for
copying Twines, most of the very compelling ones are confined
to the Twine class implementation itself, and other uses are
either dubious or easily worked around.
This patch makes Twine's copy constructor private, and fixes up
all callsites.
Differential Revision: https://reviews.llvm.org/D38767
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315530 91177308-0d34-0410-b5e6-96231b3b80d8
This forces every user to use the new create method that returns an
Expected. This in turn propagates better error messages.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@315371 91177308-0d34-0410-b5e6-96231b3b80d8
An archive looks like
<header>
<symbol table>
<tail>
The symbol table refers to offsets in the tail. A complication is that
we would like to support symbol tables that use 64 bit offsets if it
turns out that any of the offsets is too big.
This patch changes the archive writer to first compute the tail. We
cannot just compute one big StringRef since that would require reading
every member upfront, but we can represent it as a series of
StringRefs.
Having done that it is much easier to compute the symbol table and all
offsets are computed before it is written. With this if there is an
accounting problem it will show up with a regular symbol table, not
just when a 64 bit one is needed.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@314844 91177308-0d34-0410-b5e6-96231b3b80d8
Previously these were being included as both imports and
exports, with the import being satisfied by the export
(or some strong symbol) at runtime. However proved
unnecessary and actually complicated linking as it meant
there was not a 1-to-1 mapping between a wasm function
/global index and a linker symbol.
Differential Revision: https://reviews.llvm.org/D38246
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@314245 91177308-0d34-0410-b5e6-96231b3b80d8
It is useful for the symbol to contain the index of the
function of global it represents in the function/global
index space.
For imports we also store the import index so that the
linker can find, for example, the signature of the
corresponding function, which is defined by the import
In the long run we need to decide whether this API
surface should be closer to binary (where imported
functions are seperate) or the wasm spec (where the
function index space is unified).
Differential Revision: https://reviews.llvm.org/D38189
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@314230 91177308-0d34-0410-b5e6-96231b3b80d8
When dsymutil generates the companion file, its strips all unnecessary
sections by omitting their body and setting the offset in their
corresponding load command to zero.
One such section is the .eh_frame section, as it contains runtime
information rather than debug information and is part of the __TEXT
segment. When reading this section, we would just read the number of
bytes specified in the load command, starting from offset 0 (i.e. the
beginning of the file).
Rather than trying to parse this obviously invalid section, dwarfdump
now skips this.
Differential revision: https://reviews.llvm.org/D38135
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@314208 91177308-0d34-0410-b5e6-96231b3b80d8
This patch renames K_MIPS64 to K_GNU64 as part of a change to add
support for writing archives with 64-bit indexes in the symbol table.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313787 91177308-0d34-0410-b5e6-96231b3b80d8
Move logic that allows for Triple deduction from an ObjectFile object
out of llvm-objdump.cpp into a public factory, found in the ObjectFile
class.
This should allow other tools in the future to use this logic without
reimplementation.
Patch by Mitch Phillips
Differential Revision: https://reviews.llvm.org/D37719
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@313605 91177308-0d34-0410-b5e6-96231b3b80d8
This change only treats imported and exports functions and globals
as symbol table entries the object has a "linking" section (i.e. it is
relocatable object file).
In this case all globals must be of type I32 and initialized with
i32.const. This was previously being assumed but not checked for and
was causing a failure on big endian machines due to using the wrong
value of then union.
See: https://bugs.llvm.org/show_bug.cgi?id=34487
Differential Revision: https://reviews.llvm.org/D37497
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@312674 91177308-0d34-0410-b5e6-96231b3b80d8
The code wasn't previously taking into account that the
global index space is not same as the into in the Globals
array since the latter does not include imported globals.
This fixes the WebAssembly waterfall failures.
Differential Revision: https://reviews.llvm.org/D37384
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@312340 91177308-0d34-0410-b5e6-96231b3b80d8
writeArchive returned a pair, but the first element of the pair is always
its first argument on failure, so it doesn't make sense to return it from
the function. This patch change the return type so that it does't return it.
Differential Revision: https://reviews.llvm.org/D37313
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@312177 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Previously, llvm-cvtres crashes on .res files which are empty except for
the null header. This allows the library to simply pass over them.
Subscribers: llvm-commits, hiraditya
Differential Revision: https://reviews.llvm.org/D37044
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@311625 91177308-0d34-0410-b5e6-96231b3b80d8
When creating an import library from lld, the cases with
Name != ExtName shouldn't end up as a weak alias, but as a real
export of the new name, which is what actually is exported from
the DLL.
This restores the behaviour of renamed exports to what it was in
4.0.
The other half of this commit, including test, goes into lld.
Differential Revision: https://reviews.llvm.org/D36633
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@310991 91177308-0d34-0410-b5e6-96231b3b80d8
Hook up the -k option (that in the original GNU dlltool removes the
@n suffix from the symbol that the final executable ends up linked to).
In llvm-dlltool, make sure that functions end up with the undecorate
name type if this option is set and they are decorated. In mingw, when
creating import libraries from def files instead of creating an import
library as a side effect of linking a DLL, the symbol names in the def
contain the stdcall/fastcall decoration (but no leading underscore).
By setting the undecorate name type, a linker linking to the import
library will omit the decoration from the DLL import entry.
With this in place, mingw-w64 for i386 built with llvm-dlltool/clang
produces import libraries that actually work.
Differential Revision: https://reviews.llvm.org/D36548
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@310990 91177308-0d34-0410-b5e6-96231b3b80d8
