Bug: An assertion fails:
Assertion failed: isa<To>(Val) && "cast<Ty>() argument of incompatible type!",
file C:\Users\<user>\prog\llvm\llvm-git-lld-bug\llvm\include\llvm/Support/Casting.h, line 578
Bug is triggered, if
- a map file is requested with /MAP, and
- Architecture is ARMv7, Thumb, and
- a relative jump (branch instruction) is greater than 16 MiB (2^24)
The reason for the Bug is:
- a Thunk is created for the jump
- a Symbol for the Thunk is created
- of type `DefinedSynthetic`
- in file `Writer.cpp`
- in function `getThunk`
- the Symbol has no name
- when creating the map file, the name of the Symbol is queried
- the function `Symbol::computeName` of the base class `Symbol`
casts the `this` pointer to type `DefinedCOFF` (a derived type),
but the acutal type is `DefinedSynthetic`
- The in the llvm::cast an assertion fails
Changes:
- Modify regression test to trigger this bug
- Give the symbol pointing to the thunk a name, to fix the bug
- Add assertion, that only DefinedCOFF symbols are allowed to have an
empty name, when the constructor of the base class Symbol is executed
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D133201
This also modifies llvm-readobj to be more future-proof when printing
the guard FIDs table by calculating the entry size correctly according
to MS docs.
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D132924
When an object file contains an export directive, we normally do some
amount of deferred processing of them at the end of the linking
process. The -includeoptional option was handled after this, and
any object files (defining new exports) weren't handled.
Move the handling of the -includeoptional into the same late loop
which does the fixups for e.g. export directives.
Ideally, this would also be done for object files that are pulled
in by the wrap options, and for mingw autoimports, but those changes
require more modifications, to make them safe for potentially
being executed multiple times.
This fixes https://github.com/llvm/llvm-project/issues/57243.
Differential Revision: https://reviews.llvm.org/D132361
This is an entirely new embedded directive - extending the GNU ld
command line option --exclude-symbols to be usable in embedded
directives too.
(GNU ld.bfd also got support for the same new directive, currently in
the latest git version, after the 2.39 branch.)
This works as an inverse to the regular embedded dllexport directives,
for cases when autoexport of all eligible symbols is performed.
Differential Revision: https://reviews.llvm.org/D130120
This adds support for the existing GNU ld command line option, which
allows excluding individual symbols from autoexport (when linking a
DLL and no symbols are marked explicitly as dllexported).
Differential Revision: https://reviews.llvm.org/D130118
With D26647, we can already identify input object files compiled by cl.exe with
/GL. It seems to be helpful to do the same and print an error message for those
object files compiled with /GL but are inside libraries/archives too.
Reviewed By: rnk, thieta
Differential Revision: https://reviews.llvm.org/D131458
These are new debug types that ships with the latest
Windows SDK and would warn and finally fail lld-link.
The symbols seems to be related to Microsoft's XFG
which is their version of CFG. We can't handle any of
this yet, so for now we can just ignore these types
so that lld doesn't fail with a new version of Windows
SDK.
Fixes: #56285
Reviewed By: rnk
Differential Revision: https://reviews.llvm.org/D129378
llvm::sort is beneficial even when we use the iterator-based overload,
since it can optionally shuffle the elements (to detect
non-determinism). However llvm::sort is not usable everywhere, for
example, in compiler-rt.
Reviewed By: nhaehnle
Differential Revision: https://reviews.llvm.org/D130406
Print the actual number of symbols that would have been exported
too, which helps assessing the situation.
Differential Revision: https://reviews.llvm.org/D130117
This patch adds a new flag vfsoverlay similar to clang’s
ivfsoverlay flag. This is helpful when compiling on case
sensitive file systems when cross compiling to Windows.
Particularly when compiling third party code containing
\#pragma comment(“linker”, “/defaultlib:...”) which
can’t be easily changed.
Differential Revision: https://reviews.llvm.org/D125800
This reverts commit 9ffeaaa0ea.
This fixes debugging large executables with lldb and gdb.
When StringTableBuilder is used, the string offsets for any string
can point anywhere in the string table - while previously, all strings
were inserted in order (without deduplication and tail merging).
For symbols, there's no complications in encoding the string offset;
the offset is encoded as a raw 32 bit binary number in half of the
symbol name field.
For sections, the string table offset is written as
"/<decimaloffset>", but if the decimal offset would be larger than
7 digits, it's instead written as "//<base64offset>". Tools that
operate on object files can handle the base64 offset format, but
apparently neither lldb nor gdb expect that syntax when locating the
debug information section. Prior to the reverted commit, all long
section names were located at the start of the string table, so
their offset never exceeded the range for the decimal syntax.
Just reverting this change for now, as the actual benefit from it
was fairly modest.
Longer term, lld could write all long section names unoptimized
at the start of the string table, followed by all the strings for
symbol names, with deduplication and tail merging. And lldb and
gdb could be fixed to handle sections with the base64 offset syntax.
This fixes https://github.com/mstorsjo/llvm-mingw/issues/289.
Microsoft does not seem to document the flag. Ignoring it for now is probably
better than getting an unknown flag error.
Reviewed By: thakis
Differential Revision: https://reviews.llvm.org/D128231
Patch created by running:
rg -l parallelForEachN | xargs sed -i '' -c 's/parallelForEachN/parallelFor/'
No behavior change.
Differential Revision: https://reviews.llvm.org/D128140
It seems to be a bug in `LinkerDriver::findFile`, the file name is not converted
to lowercase when being inserted into `visitedLibs`. This is the only exception
in the file and all other places always convert file names to lowercase when
inserting them into `visitedLibs` (or `visitedFiles`).
Reviewed By: thieta, hans
Differential Revision: https://reviews.llvm.org/D127709
Otherwise, with recent versions of libstdc++, clang can't tell that the
atomic operations are properly aligned, and generates calls to
libatomic. (Actually, because of the use of reinterpret_cast, it wasn't
guaranteed to be aligned, but I think it ended up being aligned in
practice.)
Fixes https://github.com/llvm/llvm-project/issues/54790 , the part where
LLVM failed to build.
Differential Revision: https://reviews.llvm.org/D123872
Mostly for compatibility reasons with link.exe this flag
makes sure we don't write a implib - not even when /implib
is also passed, that's how link.exe works.
Differential Revision: https://reviews.llvm.org/D123591
Mostly for compatibility reasons with link.exe this flag
makes sure we don't write a implib - not even when /implib
is also passed, that's how link.exe works.
Reviewed By: mstorsjo
Differential Revision: https://reviews.llvm.org/D123591
lib.exe by default exits successfully without writing an output
file when no inputs are passed. llvm-lib has the same behavior,
for compatibility.
This behavior interacts poorly with build systems: If a static
library target had no inputs, llvm-lib would not produce an output
file, causing ninja (or make, or a similar system) to successfully
run that step, but then re-run it on the next build.
After this patch, llvm-lib emits a warning in this case, that with
/WX can be turned into an error. That way, ninja (or make, or...)
will mark the initial build as failed.
People who don't like the warning can use /ignore:emptyoutput to
suppress it.
The warning also points out the existing flag /llvmlibempty which
forces creation of an empty .lib file (this is an extension to lib.exe).
Differential Revision: https://reviews.llvm.org/D123517
This removes options for performing LTO with the legacy pass
manager in LLD. Options that explicitly enable the new pass manager
are retained as no-ops.
Differential Revision: https://reviews.llvm.org/D123219
Follow-up from 98bc304e9f - while that
commit fixed when you had two PDBs colliding on the same Guid it didn't
fix the case where you had more than two PDBs using the same Guid.
This commit fixes that and also tests much more carefully that all
the types are correct no matter the order.
Reviewed By: aganea, saudi
Differential Revision: https://reviews.llvm.org/D123185
Or rather, error out if it is set to something other than ON. This
removes the ability to enable the legacy pass manager by default,
but does not remove the ability to explicitly enable it through
various flags like -flegacy-pass-manager or -enable-new-pm=0.
I checked, and our test suite definitely doesn't pass with
LLVM_ENABLE_NEW_PASS_MANAGER=OFF anymore.
Differential Revision: https://reviews.llvm.org/D123126
Microsoft shipped a bunch of PDB files with broken/invalid GUIDs
which lead lld to use 0xFF as the key for these files in an internal
cache. When multiple files have this key it will lead to collisions
and confused symbol lookup.
Several approaches to fix this was considered. Including making the key
the path to the PDB file, but this requires some filesystem operations
in order to normalize the file path.
Since this only happens with malformatted PDB files and we haven't
seen this before they malformatted files where shipped with visual
studio we probably shouldn't optimize for this use-case.
Instead we now just don't insert files with Guid == 0xFF into the
cache map and warn if we get collisions so similar problems can be
found in the future instead of being silent.
Discussion about the root issue and the approach to this fix can be found on Github: https://github.com/llvm/llvm-project/issues/54487
Reviewed By: aganea
Differential Revision: https://reviews.llvm.org/D122372
So far, we sort all discardable sections at the end, with only some
extra logic to make sure that the .reloc section is at the start
of that group of sections. But if there are other discardable
sections, other than .reloc, they must also be ordered before
.debug_* sections, to avoid leaving gaps if the executable is
stripped.
(Stripping executables doesn't remove all discardable sections,
only the ones named .debug_*).
Rust binaries seem to include a .rmeta section, which is marked
discardable. This fixes stripping such binaries if built with
dwarf debug info included.
This fixes issues observed in MSYS2 in
https://github.com/msys2/MINGW-packages/pull/10555.
Differential Revision: https://reviews.llvm.org/D120805
This does tail merging (and deduplication) of the strings.
On a statically linked clang.exe, this shrinks the ~17 MB string
table by around 0.5 MB. This adds ~160 ms to the linking time
which originally was around 950 ms.
For cases where `-debug:symtab` or `-debug:dwarf` isn't set, the
string table is only used for long section names, where this
shouldn't make any difference at all.
Differential Revision: https://reviews.llvm.org/D120677
The previous code used an unbounded sprintf, which in theory can
overflow, writing either the null terminator or the last digits
into the next struct member.
In practice, in LLD, all long section names are written sequentially
first at the start of the string table, followed by all the long
symbol names. Due to this, even if the total string table would
end up large, the long section names have fairly short offsets,
which is why this hasn't been an issue in practice.
I don't think it's worth trying to write a test that produces an
executable with enough long section names to make the section names
themselves exceed 10^6 bytes, which is currently necessary to trigger
faults with the previous form.
Differential Revision: https://reviews.llvm.org/D120676
This relands 73e585e44d (and 0574b5fc65), with a fix for
the failing test (by using Optional<StringRef>s instead of
making StringRef::empty() mean absence of value).
Differential Revision: https://reviews.llvm.org/D118070
Makes lld-link work in a non-MSVC shell by autodetecting MSVC toolchain. Also
adds support for /winsysroot and a few other switches.
All this is done by refactoring to share code with clang-cl's existing support
for the same.
Differential Revision: https://reviews.llvm.org/D118070
This reverts commit ef82063207.
- It conflicts with the existing llvm::size in STLExtras, which will now
never be called.
- Calling it without llvm:: breaks C++17 compat
D46245 added support for this in llvm-libtool, but while lld-link can
also create .lib files from .def files it didn't support aliases.
I compared the Inputs/library.def test against the output from
llvm-libtool and it matches, except for the fact that lld-link reorders
functions for some reason.
I have also verified that this fixes a bug I was running into while
trying to compile .def files to .lib files in MinGW-w64 (using lld-link
instead of llvm-libtool).
Differential Revision: https://reviews.llvm.org/D113365
Jan Ole Hüser