https://github.com/llvm/llvm-project/pull/134787 unintentionally enabled `--mmap-output-file` by default under LLD which caused the Windows-only test `lld\test\ELF\link-open-file.test` to fail. This failure uncovered what appears to be an inconsistency on Windows between `createOnDiskBuffer` and `createInMemoryBuffer` with respect to `DELETE` access for the output file. The output file created by `createOnDiskBuffer` sets the flag `OF_Delete` as part of `fs::TempFile::create` while the output file created by `createInMemoryBuffer` sets `OF_None` under `InMemoryBuffer::commit`. The test `lld\test\ELF\link-open-file.test` ensures that if `FILE_SHARE_DELETE` is _not_ specified for an output file that LLD is expected to overwrite, LLD should fail. This only happens if: "the file or device has been opened for delete access" which is only done for `fs::TempFile::create`. See https://learn.microsoft.com/en-us/windows/win32/api/fileapi/nf-fileapi-createfilew#FILE_SHARE_DELETE. Therefore, I propose setting `OF_Delete` for `InMemoryBuffer::commit`'s call to `openFileForWrite` to stay consistent with `fs::TempFile::create`.
`F_no_mmap` introduced by https://reviews.llvm.org/D69294 is misnamed. It oughts to be `F_mmap` When the output is a regular file or do not exist, `--no-mmap-output-file` is the default. Relands #134787 by fixing the lld option default. Note: changing the default to --map-output-file would likely fail on llvm-clang-x86_64-sie-win (https://lab.llvm.org/buildbot/#/builders/46/builds/14847) Pull Request: https://github.com/llvm/llvm-project/pull/139836
Reverts llvm/llvm-project#134787 Causes the LIT test `lld\test\ELF\link-open-file.test` to fail on the `llvm-clang-x86_64-sie-win` Build Bot. First instance of the failure observed in: https://lab.llvm.org/buildbot/#/builders/46/builds/14847
The `F_no_mmap` flag was introduced by https://github.com/llvm/llvm-project/commit/68142324290f2932df0e271747cdccc371d6dded
This adds support for generating Chrome-tracing .json profile traces in the LLD COFF driver. Also add the necessary time scopes, so that the profile trace shows in great detail which tasks are executed. As an example, this is what we see when linking a Unreal Engine executable: 
The cleanup was manual, but assisted by "include-what-you-use". It consists in 1. Removing unused forward declaration. No impact expected. 2. Removing unused headers in .cpp files. No impact expected. 3. Removing unused headers in .h files. This removes implicit dependencies and is generally considered a good thing, but this may break downstream builds. I've updated llvm, clang, lld, lldb and mlir deps, and included a list of the modification in the second part of the commit. 4. Replacing header inclusion by forward declaration. This has the same impact as 3. Notable changes: - llvm/Support/TargetParser.h no longer includes llvm/Support/AArch64TargetParser.h nor llvm/Support/ARMTargetParser.h - llvm/Support/TypeSize.h no longer includes llvm/Support/WithColor.h - llvm/Support/YAMLTraits.h no longer includes llvm/Support/Regex.h - llvm/ADT/SmallVector.h no longer includes llvm/Support/MemAlloc.h nor llvm/Support/ErrorHandling.h You may need to add some of these headers in your compilation units, if needs be. As an hint to the impact of the cleanup, running clang++ -E -Iinclude -I../llvm/include ../llvm/lib/Support/*.cpp -std=c++14 -fno-rtti -fno-exceptions | wc -l before: 8000919 lines after: 7917500 lines Reduced dependencies also helps incremental rebuilds and is more ccache friendly, something not shown by the above metric :-) Discourse thread on the topic: https://llvm.discourse.group/t/include-what-you-use-include-cleanup/5831
Update llvm::sys::fs::mapped_file_region to have a move constructor and a move assignment operator, allowing it to be used as an Optional. Also, update FileOutputBuffer's OnDiskBuffer to take advantage of this, avoiding an extra allocation from the unique_ptr. A nice follow-up would be to make the mapped_file_region constructor private and replace its use with a factory function, such as mapped_file_region::create(), that returns an Expected (or ErrorOr). I don't plan on doing that immediately, but I might swing back later. No functionality change, besides the saved allocation in OnDiskBuffer. Differential Revision: https://reviews.llvm.org/D100159
Add a variant of `fs::resize_file` for use immediately before opening a file with `mapped_file_region::readwrite`. On Windows, `_chsize` (`ftruncate`) is slow, but `CreateFileMapping` (`mmap`) automatically extends the file so the call to `fs::resize_file` can be skipped. This optimization was added to `FileOutputBuffer` in da9bc2e56d5a5c6332a9def1a0065eb399182b93; this commit just extracts the logic out and adds a unit test. Differential Revision: https://reviews.llvm.org/D95490
The D93881 added functionality which preserve ownership for output file if llvm-objcopy is called under root. That code was added into the place where output file is created. The llvm-objcopy already has a function which sets/restores rights/permissions for the output file. That is the restoreStatOnFile() function. This patch moves code (preserving ownershipping) into the restoreStatOnFile() function. Differential Revision: https://reviews.llvm.org/D98511
As of binutils 2.36, GNU strip calls chown(2) for "sudo strip foo" and "sudo strip foo -o foo", but no "sudo strip foo -o bar" or "sudo strip foo -o ./foo". In other words, while "sudo strip foo -o bar" creates a new file bar with root access, "sudo strip foo" will keep the owner and group of foo unchanged. Currently llvm-objcopy and llvm-strip behave differently, always changing the owner and gropu to root. The discrepancy prevents Chrome OS from migrating to llvm-objcopy and llvm-strip as they change file ownership and cause intended users/groups to lose access when invoked by sudo with the following sequence (recommended in man page of GNU strip). 1.<Link the executable as normal.> 1.<Copy "foo" to "foo.full"> 1.<Run "strip --strip-debug foo"> 1.<Run "objcopy --add-gnu-debuglink=foo.full foo"> This patch makes llvm-objcopy and llvm-strip follow GNU's behavior. Link: crbug.com/1108880