These files satisfy all of the following: - misc-include-cleaner indicates that these files do not need Endian.h. - They do not mention "endian" anywhere. - They do not include any *.inc or *.def, which could need llvm::support::endian.
accumulated preprocessed size: before: 1065515095 after: 1065629059 Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup Differential Revision: https://reviews.llvm.org/D120195
Most PDB fields on disk are 32-bit but describe the file in terms of MSF blocks, which are 4 kiB by default. So PDB files can be a bit larger than 4 GiB, and much larger if you create them with a block size > 4 kiB. This is a first (necessary, but by far not not sufficient) step towards supporting such PDB files. Now we don't truncate in-memory file offsets (which are in terms of bytes, not in terms of blocks). No effective behavior change. lld-link will still error out if it were to produce PDBs > 4 GiB. Differential Revision: https://reviews.llvm.org/D109923
Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. llvm-svn: 369013
to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
The existing library assumed that a stream's length would never change. This makes some things simpler, but it's not flexible enough for what we need, especially for writable streams where what you really want is for each call to write to actually append. llvm-svn: 319070
The PDB reserves certain blocks for the FPM that describe which blocks in the file are allocated and which are free. We weren't filling that out at all, and in some cases we were even stomping it with incorrect data. This patch writes a correct FPM. Differential Revision: https://reviews.llvm.org/D36235 llvm-svn: 309896
Recently problems have been discovered in the way we write the FPM (free page map). In order to fix this, we first need to establish a baseline about what a correct FPM looks like using an MSVC generated PDB, so that we can then make our own generated PDBs match. And in order to do this, the dumper needs a mode where it can dump an FPM so that we can write tests for it. This patch adds a command to dump the FPM, as well as a test against a known-good PDB. llvm-svn: 309894
llvm-svn: 306169
Previously MappedBlockStream owned its own BumpPtrAllocator that it would allocate from when a read crossed a block boundary. This way it could still return the user a contiguous buffer of the requested size. However, It's not uncommon to open a stream, read some stuff, close it, and then save the information for later. After all, since the entire file is mapped into memory, the data should always be available as long as the file is open. Of course, the exception to this is when the data isn't *in* the file, but rather in some buffer that we temporarily allocated to present this contiguous view. And this buffer would get destroyed as soon as the strema was closed. The fix here is to force the user to specify the allocator, this way it can provide an allocator that has whatever lifetime it chooses. Differential Revision: https://reviews.llvm.org/D33858 llvm-svn: 304623