Peter Collingbourne suggested moving the switch to the top of the
function, so that all the code that cares about the output section for a
symbol is in the same place.
Differential Revision: https://reviews.llvm.org/D47497
llvm-svn: 333472
Rather than using a loop to compare symbol RVAs to the starting RVAs of
sections to determine which section a symbol belongs to, just get the
output section of a symbol directly via its chunk, and bail if the
symbol doesn't have an output section, which avoids having to hardcode
logic for handling dead symbols, CodeView symbols, etc. This was
suggested by Reid Kleckner; thank you.
This also fixes writing out symbol tables in the presence of RVA table
input sections (e.g. .sxdata and .gfids). Such sections aren't written
to the output file directly, so their RVA is 0, and the loop would thus
fail to find an output section for them, resulting in a segfault. Extend
some existing tests to cover this case.
Fixes PR37584.
Differential Revision: https://reviews.llvm.org/D47391
llvm-svn: 333450
- Move some common code into Common/rrorHandler.cpp and
Common/Strings.h.
- Don't use `fatal` when incompatible bitcode files are
encountered.
- Rename NameRef variable to just Name
See D47162
Differential Revision: https://reviews.llvm.org/D47206
llvm-svn: 333021
Previously we emitted 20-byte SHA1 hashes. This is overkill
for identifying debug info records, and has the negative side
effect of making object files bigger and links slower. By
using only the last 8 bytes of a SHA1, we get smaller object
files and ~10% faster links.
This modifies the format of the .debug$H section by adding a new
value for the hash algorithm field, so that the linker will still
work when its object files have an old format.
Differential Revision: https://reviews.llvm.org/D46855
llvm-svn: 332669
Previously we would always write a hash of the binary into the
PE file, for reproducible builds. This breaks AppCompat, which
is a feature of Windows that relies on the timestamp in the PE
header being set to a real value (or at the very least, a value
that satisfies certain properties).
To address this, we put the old behavior of writing the hash
behind the /Brepro flag, which mimics MSVC linker behavior. We
also match MSVC default behavior, which is to write an actual
timestamp to the PE header. Finally, we add the /TIMESTAMP
option (an lld extension) so that the user can specify the exact
value to be used in case he/she manually constructs a value which
is both reproducible and satisfies AppCompat.
Differential Revision: https://reviews.llvm.org/D46966
llvm-svn: 332613
This is needed to avoid merging two functions with identical
instructions but different xdata. It also reduces binary size by
deduplicating identical pdata sections.
Fixes PR35337.
Differential Revision: https://reviews.llvm.org/D46672
llvm-svn: 332169
We discovered (crbug.com/838449#c24) that string tail merging can
negatively affect compressed binary size, so provide a flag to turn
it off for users who care more about compressed size than uncompressed
size.
Differential Revision: https://reviews.llvm.org/D46780
llvm-svn: 332149
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
Previously this was only supported when specified on the command line
or in directives.
Differential Revision: https://reviews.llvm.org/D46244
llvm-svn: 331900
The operator == used for exporting a function with a different
name in the DLL compared to the name in the import library
(which is useful for adding linker level aliases for function
in the import library) is a feature distinct and different from
the operator = used for exporting a function with a different
name (both in import library and DLL) than in the implementation
producing the DLL.
When creating an import library using dlltool, from a def file that
contains forwards (Func = OtherDll.Func), this shouldn't affect the
produced import library, which should still behave just as if it
was a normal exported function.
This clears a lot of confusion and subtle misunderstandings, and
avoids a parameter that was used to avoid creating weak aliases
when invoked from lld. (This parameter was added previously due to
the existing conflation of the two features.)
Differential Revision: https://reviews.llvm.org/D46245
llvm-svn: 331860
Now only IMAGE_REL_ARM64_ABSOLUTE and IMAGE_REL_ARM64_TOKEN
are unhandled.
Also add range checks for the existing BRANCH26 relocation.
Differential Revision: https://reviews.llvm.org/D46354
llvm-svn: 331505
Summary:
When a symbol refers to a special section or a section that doesn't
exist, lld would fatal with "broken object file". This change gives a
different message for each scenario, and includes the name of the
file, name of the symbol, and the section being referred to.
Reviewers: pcc, ruiu
Reviewed By: ruiu
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D46090
llvm-svn: 330883
Summary:
In a number of places in the COFF linker, we were calling
MemoryBuffer::getFile() with default parameters. This causes LLVM to
NUL-terminate the buffers, which can prevent them from being memory
mapped. Since we operate on binary and do not use NUL as an indicator
of the end of the file content, this change causes us to not require
the NUL terminator anymore.
Reviewers: ruiu, pcc
Reviewed By: ruiu
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D45909
llvm-svn: 330786
With MSVC linker, /DEBUG is an alias of /DEBUG:FASTLINK, and if
you don't want /DEBUG:FASTLINK you have to explicitly specify
/DEBUG:FULL.
LLD doesn't support /DEBUG:FASTLINK, and so our standard /DEBUG
option is what MSVC calls /DEBUG:FULL. To provide command line
compatibility with MSVC, we should also support /DEBUG:FULL, and
since it's the same as what LLD already does for /DEBUG, just
alias it.
llvm-svn: 330647
Summary:
ubsan found that we sometimes pass nullptr to memcpy in
SectionChunk::writeTo(). This change adds a check that avoids that.
Reviewers: ruiu
Reviewed By: ruiu
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D45789
llvm-svn: 330490
This is what link.exe does and lets us avoid needing to worry about
merging output characteristics while adding input sections to output
sections.
With this change we can't process /merge in the same way as before
because sections with different output characteristics can still
be merged into one another. So this change moves the processing of
/merge to just before we assign addresses. In the case where there
are multiple output sections with the same name, link.exe only merges
the first section with the source name into the first section with
the target name, and we do the same.
At the same time I also implemented transitive merging (which means
that /merge:.c=.b /merge:.b=.a merges both .c and .b into .a).
This isn't quite enough though because link.exe has a special case for
.CRT in 32-bit mode: it processes sections whose output characteristics
are DATA | R | W as though the output characteristics were DATA | R
(so that they get merged into things like constructor lists in the
expected way). Chromium has a few such sections, and it turns out
that those sections were causing the problem that resulted in r318699
(merge .xdata into .rdata) being reverted: because of the previous
permission merging semantics, the .CRT sections were causing the entire
.rdata section to become writable, which caused the SEH runtime to
crash because it apparently requires .xdata to be read-only. This
change also implements the same special case.
This should unblock being able to merge .xdata into .rdata by default,
as well as .bss into .data, both of which will be done in followups.
Differential Revision: https://reviews.llvm.org/D45801
llvm-svn: 330479
It's possible to have an empty object file, for example if you
just compile an empty .c file. This file won't have any sections
so asserting that a file has chunks is definitely wrong.
llvm-svn: 330461
Part of the DBI stream is a list of variable length structures
describing each module that contributes to the final executable.
One member of this structure is a section contribution entry that
describes the first section contribution in the output file for
the given module.
We have been leaving this structure unpopulated until now, so with
this patch it is now filled out correctly.
Differential Revision: https://reviews.llvm.org/D45832
llvm-svn: 330457
In an upcoming change I will need to make a distinction between section
type (code, data, bss) and permissions. The term that I use for both
of these things is "output characteristics".
Differential Revision: https://reviews.llvm.org/D45799
llvm-svn: 330361
Summary:
DLLs and executables with no exception handlers need to be marked with
IMAGE_DLL_CHARACTERISTICS_NO_SEH, even if they have a load config.
Discovered here when building Chromium with LLD on Windows:
https://crbug.com/833951
Reviewers: ruiu, mstorsjo
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D45778
llvm-svn: 330300
Summary:
This change does three things:
- Try to find the file and line number of an undefined symbol
reference by reading codeview debug info.
- Try to find the name of the function or global variable with the
undefined symbol reference by searching the object file's symbol
table.
- Prints the information in the same style as the ELF linker.
Differential Revision: https://reviews.llvm.org/D45467
llvm-svn: 330235
In this reland I removed an unnecessary use of /debug in the test
delayimports32.test and used the /pdbaltpath flag in the test
pdb-publics-import.test, both of which avoid embedding absolute PDB
paths in executables which could affect later RVAs.
Original commit message:
> COFF: Merge .idata, .didat and .edata into .rdata by default.
>
> This saves a little space and matches what link.exe does.
>
> Tested using the chromium Windows trybots:
> https://chromium-review.googlesource.com/c/chromium/src/+/1014784
Differential Revision: https://reviews.llvm.org/D45737
llvm-svn: 330233
I needed to revert r330223 because we were embedding an absolute PDB
path in the .rdata section, which ended up being laid out before the
.idata section and affecting its RVAs. This flag will let us control
the embedded path.
Differential Revision: https://reviews.llvm.org/D45747
llvm-svn: 330232
Using Config->is64() will treat ARM64 as Amd64, which is incorrect.
Furthermore, there are more esoteric architectures that could
theoretically be encountered. Just set it directly to the machine
type, which we already know anyway.
llvm-svn: 330157
Most of these are pretty trivial and obvious. Setting the toolchain
version to 14.11 is perhaps a little questionable, but we've been bitten
in the past where one of our version fields sidn't match MSVC's, and I
definitely don't want to go through that diagnosis again as it was
pretty time consuming and hard to track down.
I found all of these by using llvm-pdbutil export to dump the dbi and
pdb streams to a file, then using fc followed by llvm-pdbutil explain to
explain the mismatched bytes.
There are still some more, these are just the low hanging fruit.
Differential Revision: https://reviews.llvm.org/D45276
llvm-svn: 330130
LLVM_ON_WIN32 is set exactly with MSVC and MinGW (but not Cygwin) in
HandleLLVMOptions.cmake, which is where _WIN32 defined too. Just use the
default macro instead of a reinvented one.
See thread "Replacing LLVM_ON_WIN32 with just _WIN32" on llvm-dev and cfe-dev.
No intended behavior change.
llvm-svn: 329696
With this, all output sections are created in one place. This will make
it simpler to implement merging of builtin sections.
Differential Revision: https://reviews.llvm.org/D45349
llvm-svn: 329370
One place where this seems to matter is to make sure the .rsrc section comes
after .text. The Win32 UpdateResource() function can change the contents of
.rsrc. It will move the sections that come after, but if .text gets moved, the
entry point header will not get updated and the executable breaks. This was
found by a test in Chromium.
Differential Revision: https://reviews.llvm.org/D45260
llvm-svn: 329221
Shoaib Meenai