Add DTLTO linker option `--thinlto-remote-compiler-prepend-arg` to
enable support for the multi-call LLVM driver that requires an
additional option to specify the subcommand, e.g. "llvm clang ...".
Fixes https://github.com/llvm/llvm-project/issues/159125.
Follow-up to https://reviews.llvm.org/D57974, which added calls to
Archive::Child::getFullName() to produce strings in errors.
But getFullName() is only valid on thin archives, and should only be
used to open the file the archive points to. For diagnostics, getName()
is better: It works for both thin and non-thin files, and it doesn't
make a very long string for thin files. And we already prepend the name
of the parent archive file anyways.
Resolves#141712.
As described in the issue, this PR adds support for `/nodbgdirmerge`
flag in LLD to align with MS link. When the flag is specified, the
linker will emit the debug directory section in `.cvinfo` section,
instead of merging it to the `.rdata`. The flag will be ignored on
MinGW.
---------
Co-authored-by: namazso <admin@namazso.eu>
When `/summary` is used, we now also display the cumulative size of all
input OBJ files, including those pulled from archives. Lazy OBJ files
that were not pulled in are not accounted for.
Also added separators between digit groups, to make the output more
bearable.
Example output:
```
> lld-link ... /summary
Summary
--------------------------------------------------------------------------------
4,958 Input OBJ files (expanded from all cmd-line inputs)
46,715,790,512 Size of all consumed OBJ files (non-lazy), in bytes
42 PDB type server dependencies
0 Precomp OBJ dependencies
293,910,064 Input type records
16,931,361,928 Size of all input type records, in bytes
11,201,549 Merged TPI records
2,765,494 Merged IPI records
38,649 Output PDB strings
21,512,230 Global symbol records
82,380,837 Module symbol records
715,313 Public symbol records
```
I've skipped over the exact amounts for "Size of all consumed inputs
(non-lazy)" in the unit tests, since the sizes of OBJ files can
fluctuate between compilers.
_(this is a reopening of
https://github.com/llvm/llvm-project/pull/157279 which wasa committed by
mistake)_
Those are all MS link.exe compatible flags.
### CET (Control-flow Enforcement Technology) family
- Added LLD test that covers `/cetcompat[:no]`
- Added `/cetcompatstrict[:no]` flag in LLD/COFF
- Added `/cetipvalidationrelaxed[:no]` flag in LLD/COFF
- Added `/cetdynamicapisinproc[:no]` flag in LLD/COFF
### Misc
- Added `/hotpatchcompatible[:no]` flag in LLD/COFF
- This flag requires at least 6 bytes of function padding
(`/functionpadmin:#`) as per link.exe
When `/summary` is used, we now also display the cumulative size of all
input OBJ files, including those pulled from archives. Lazy OBJ files
that were not pulled in are not accounted for.
Also added separators between digit groups, to make the output more
bearable.
Example output:
```
> lld-link ... /summary
Summary
--------------------------------------------------------------------------------
4,958 Input OBJ files (expanded from all cmd-line inputs)
46,715,790,512 Size of all consumed OBJ files (non-lazy), in bytes
42 PDB type server dependencies
0 Precomp OBJ dependencies
293,910,064 Input type records
16,931,361,928 Size of all input type records, in bytes
11,201,549 Merged TPI records
2,765,494 Merged IPI records
38,649 Output PDB strings
21,512,230 Global symbol records
82,380,837 Module symbol records
715,313 Public symbol records
```
We skip over the exact amounts for "Size of all consumed inputs
(non-lazy)" in the unit tests, since the sizes of OBJ files can
fluctuate between compilers.
MS link.exe provides the `/sectionlayout:@` option to specify the order
of output sections at the granularity of individual sections. LLD/COFF
currently does not have capability for user-controlled ordering of one
or more output sections (as LLD/COFF does not support linker scripts),
and this PR adds the option to align with MS link.exe.
The option accepts only a file that specifies the order of sections, one
per line. For example, `mylayout.txt` could emit the `.text` section
after all other sections while preserving the original relative order of
the remaining sections.
```
.data
.rdata
.pdata
.rsrc
.reloc
.text
```
```bash
echo 'int main() { return 0; }' > main.c
cl main.c /link /entry:main /sectionlayout:@mylayout.txt
llvm-readobj --sections main.exe
```
Fixes crashes reported in #151255.
The alias may have already been stored for later resolution, which can
lead to treating a resolved alias as if it were still undefined.
Instead, use the alias target directly for the import.
Also extended the test to make reproducing the problem more likely, and
added an assert that catches the issue.
Fixes MSVC CRT thread-local constructors support on hybrid ARM64X
targets.
`-arm64xsameaddress` is an undocumented option that ensures the
specified function has the same address in both native and EC views of
hybrid images. To achieve this, the linker emits additional thunks and
replaces the symbols
of those functions with the thunk symbol (the same thunk is used in both
views). The thunk code jumps to the native function (similar to range
extension thunks), but additional ARM64X relocations are emitted to
replace the target with the EC function in the EC view.
MSVC appears to generate thunks even for non-hybrid ARM64EC images. As a
side effect, the native symbol is pulled in. Since this is used in the
CRT for thread-local constructors, it results in the image containing
unnecessary native code. Because these thunks do not appear to be useful
in that context, we limit this behavior to actual hybrid targets. This
may change if compatibility requires it.
The tricky part is that thunks should be skipped if the symbol is not
live in either view, and symbol replacement must be reflected in weak
aliases. This requires thunk generation to happen before resolving weak
aliases but after the GC pass. To enable this, the `markLive` call was
moved earlier, and the final weak alias resolution was postponed until
afterward. This requires more code to be aware of weak aliases, which
previously could assume they were already resolved.
A thin archive is an archive/library format where the archive itself
contains only references to member object files on disk, rather than
embedding the file contents.
For the non-/wholearchive case, we use the path to the archive member as
the identifier for thin-archive members (see comments in
`enqueueArchiveMember`). This patch modifies the /wholearchive path to
behave the same way.
Apart from consistency, my motivation for fixing this is DTLTO
(#126654), where having the member identifier be the path on disk allows
distribution of bitcode members during ThinLTO.
This is a follow-up PR for post-commit comments in
https://github.com/llvm/llvm-project/pull/146610
- Changed "exporteddllmain" references to "importeddllmain".
- Add support for x86 target and test coverage.
- Changed a comment to better express why we're skipping importing
`DllMain`.
This patch introduces support for Integrated Distributed ThinLTO (DTLTO)
in COFF LLD.
DTLTO enables the distribution of ThinLTO backend compilations via
external distribution systems, such as Incredibuild, during the
traditional link step: https://llvm.org/docs/DTLTO.html.
Note: Bitcode members of non-thin archives are not currently supported.
This will be addressed in a future change. This patch is sufficient to
allow for self-hosting an LLVM build with DTLTO if thin archives are
used.
Testing:
- LLD `lit` test coverage has been added, using a mock distributor to
avoid requiring Clang.
- Cross-project `lit` tests cover integration with Clang.
For the design discussion of the DTLTO feature, see:
https://github.com/llvm/llvm-project/pull/126654
This is a workaround for
https://github.com/llvm/llvm-project/issues/82050 by skipping the `DllMain` symbol if seen in aimport library. If this situation occurs, after this commit a warning will also be displayed. The warning can be silenced with `/ignore:exporteddllmain`
If any of the Windows SDK (and MSVC)-related argument is passed in the
command line, they should take priority over the environment variables
like `INCLUDE` or `LIB` set by vcvarsall from the Visual Studio
Developer Environment on Windows.
These changes ensure that all of the arguments related to VC Tools and
the Windows SDK cause the driver to ignore the environment.
MSVC linker accepts native ARM64 object files as input with
`-machine:arm64ec`, similar to `-machine:arm64x`. Its usefulness is very
limited; for example, both exports and imports are not reflected in the
PE structures and can't work. However, their symbol tables are otherwise
functional.
Since we already have handling of multiple symbol tables implemented for
ARM64X, the required changes are mostly about adjusting relevant checks
to account for them on the ARM64EC target.
Delay-load helper handling is a bit of a shortcut. The patch never pulls
it for native object files and just ensures that the code is fine with
that. In general, I think it would be nice to adjust the driver to pull
it only when it's actually referenced, which would allow applying the
same logic to the native symbol table on ARM64EC without worrying about
pulling too much.
Cygwin requires these symbols for its fork emulation to know what data
to copy into the child. GNU ld defines these symbols for MinGW targets
also, so do the same here.
Cygwin also has the `.data_cygwin_nocopy` section, which is merged into
`.data` outside the `__data_start__` to `__data_end__` range. This
excludes it from fork's copying. AFAIK it's only used by the Cygwin DLL
itself (which requires a custom linker script to link, that's not
supported by LLD), but the section is included in GNU ld's default
linker script so handle it here too.
Signed-off-by: Jeremy Drake <github@jdrake.com>
Originally, the intent behind symtab was to represent the symbol table
seen in the PE header (without applying ARM64X relocations). However, in
most cases outside of `writeHeader()`, the code references either both
symbol tables or only the EC one, for example, `mainSymtab` in
`linkerMain()` maps to `hybridSymtab` on ARM64X.
MSVC's link.exe allows pure ARM64EC images to include native ARM64
files. This patch prepares LLD to support the same, which will require
`hybridSymtab` to be available even for ARM64EC. At that point,
`writeHeader()` will need to use the EC symbol table, and the original
reasoning for keeping it in `hybridSymtab` no longer applies.
Given this, it seems cleaner to treat the EC symbol table as the “main”
one, assigning it to `symtab`, and use `hybridSymtab` for the native
symbol table instead. Since `writeHeader()` will need to be conditional
anyway, this change simplifies the rest of the code by allowing other
parts to consistently treat `ctx.symtab` as the main symbol table.
As a further simplification, this also allows us to eliminate `symtabEC`
and use `symtab` directly; I’ll submit that as a separate PR.
The map file now uses the EC symbol table for printed entry points and
exports, matching MSVC behavior.
This reverts commit 6a1bdd9 and re-instate behavior that matches what
MSVC link.exe does, that is, error out when trying to dllimport a symbol
from a static library.
A hint is now displayed in stdout, mentioning that we should rather dllimport the symbol
from a import library.
Fixes https://github.com/llvm/llvm-project/issues/131807
This change implements support for the /stub flag to align with MS
link.exe. This option is useful when a program needs to optimize the DOS
program that executes when the PE runs on DOS, avoiding the traditional
hardcoded DOS program in LLD.
This refactor prepares for further ARM64X hybrid support, where these
helpers will need to work with either the native or EC symbol table
based on context.
Move `LinkerDriver::addUndefined` to` SymbolTable` to allow its use with
both symbol tables on ARM64X and rename it to `addGCRoot` to clarify its
distinct role compared to the existing `SymbolTable::addUndefined`.
Command-line `-include` arguments now apply to the EC symbol table, with
`mainSymtab` introduced in `linkerMain`. There will be more similar
cases. For `.drectve` sections, the corresponding symbol table is used
based on the context.
cg_profile in object is from CGProfilePass and it is often inaccurate.
While call-graph-ordering-file is provided by user. It is weird to
aggregate them together especially when call-graph-ordering-file is
accurate enough.
