In PR21682 Jean-Daliel Dupas found a leak in the trie builder and suggested
a fix was to use a list instead of SmallVector so that the list elements
could be allocated in the BumpPtrAllocator.
llvm-svn: 223104
The AtomSections were improperly merging sections from various input files. This
patch fixes the problem, with an updated test that was provided by Simon.
Thanks to Simon Atanasyan for catching this issue.
llvm-svn: 222982
Opening a file using openFileForWrite and closing it using close
was asymmetric. It also had a subtle portability problem (details are
described in the commit message for r219189).
llvm-svn: 222802
This was basically benign resource leak on Unix, but on Windows
it could cause builds to fail because opened file descriptor
prevents other processes from moving or removing the file.
llvm-svn: 222799
There are many build files in the wild that depend on the fact that
link.exe produces a PDB file if /DEBUG option is given. They fail
if the file is not created.
This patch is to make LLD create an empty (dummy) file to satisfy
such build targets. This doesn't do anything other than "touching"
the file.
If a target depends on the content of the PDB file, this workaround
is no help, of course. Otherwise this patch should help build some
stuff.
llvm-svn: 222773
Export table entries need to be sorted in ASCII-betical order,
so that the loader can find an entry for a function by binary search.
We sorted the entries by its mangled names. That can be different
from their exported names. As a result, LLD produces incorrect export
table, from which the loader complains that a function that actually
exists in a DLL cannot be found.
This patch fixes that issue.
llvm-svn: 222452
This reverts commit r222310.
Not sure which commit is the cause of the failure on the darwin bot. Will need
to revert my changes and commit one change at a time.
llvm-svn: 222330
Mach-o does not use a simple SO_NEEDED to track dependent dylibs. Instead,
the linker copies four things from each dylib to each client: the runtime path
(aka "install name"), the build time, current version (dylib build number), and
compatibility version The build time is no longer used (it cause every rebuild
of a dylib to be different). The compatibility version is usually just 1.0
and never changes, or the dylib becomes incompatible.
This patch copies that information into the NormalizedMachO format and
propagates it to clients.
llvm-svn: 222300
This patch fixes the following MSVC warning.
warning C4334: '<<' : result of 32-bit shift implicitly
converted to 64 bits (was 64-bit shift intended?)
llvm-svn: 222293
When fixing up BL instructions, the linker has to compare the thumbness of the
target to decide if the instruction needs to be converted to BLX. But with B
instruction there is no BX, so the linker asserts if the target is not the
same thumbness. This assert was firing in -r mode when the target was undefined
which it interpreted as being non-thumb.
Test case change is to add a B (in both thumb and arm code) to an undefined
symbol and round trip through -r mode.
llvm-svn: 222266
The arm64 assembler almost always uses r_extern=1 relocations in which the
r_symbolnum field is the index of the symbol the relocation references. But
sometimes it will set r_extern=0 in which case the linker needs to read the
content of the reloction to determine the target.
Add test case that the r_extern=0 relocation round trips.
llvm-svn: 222200
The arm64 assembler almost always uses r_extern=1 relocations in which the
r_symbolnum field is the index of the symbol the relocation references. But
sometimes it will set r_extern=0 in which case the linker needs to read the
content of the reloction to determine the target.
Add test case that the r_extern=0 relocation round trips.
llvm-svn: 222198
If you have something like
__declspec(align(8192)) int foo = 1;
in your code, the compiler makes the data to be aligned to 8192-byte
boundary, and the linker align the section containing the data to 8192.
LLD always aligned the section to 4192. So, as long as alignment
requirement is smaller than 4192, it was correct, but for larger
requirements, it's wrong.
This patch fixes the issue.
llvm-svn: 222043
AddressOfEntryPoint is overridden after we layout all atoms (until then,
we don't know the entry point address for obvious reason.)
I believe this code is leftover from very early version of the
PE/COFF port that we only had an entry function in a test object file.
llvm-svn: 222026
