summaryrefslogtreecommitdiff
path: root/lldb/source/Core/DataFileCache.cpp
AgeCommit message (Collapse)Author
2025-04-22Modify the localCache API to require an explicit commit on CachedFile… ↵anjenner
(#136121) …Stream. CachedFileStream has previously performed the commit step in its destructor, but this means its only recourse for error handling is report_fatal_error. Modify this to add an explicit commit() method, and call this in the appropriate places with appropriate error handling for the location. Currently the destructor of CacheStream gives an assert failure in Debug builds if commit() was not called. This will help track down any remaining uses of the API that assume the old destructior behaviour. In Release builds we fall back to the previous behaviour and call report_fatal_error if the commit fails. This is version 2 of this PR, superseding reverted PR https://github.com/llvm/llvm-project/pull/115331 . I have incorporated a change to the testcase to make it more reliable on Windows, as well as two follow-up changes (https://github.com/llvm/llvm-project/commit/df79000896101acc9b8d7435e59f767b36c00ac8 and https://github.com/llvm/llvm-project/commit/b0baa1d8bd68a2ce2f7c5f2b62333e410e9122a1) that were also reverted when 115331 was reverted. --------- Co-authored-by: Augie Fackler <augie@google.com> Co-authored-by: Vitaly Buka <vitalybuka@google.com>
2025-03-08Revert "Modify the localCache API to require an explicit commit on ↵Douglas Yung
CachedFile… (#115331)" This reverts commit ce9e1d3c15ed6290f1cb07b482939976fa8115cd. The unittest added in this commit seems to be flaky causing random failure on buildbots: - https://lab.llvm.org/buildbot/#/builders/46/builds/13235 - https://lab.llvm.org/buildbot/#/builders/46/builds/13232 - https://lab.llvm.org/buildbot/#/builders/46/builds/13228 - https://lab.llvm.org/buildbot/#/builders/46/builds/13224 - https://lab.llvm.org/buildbot/#/builders/46/builds/13220 - https://lab.llvm.org/buildbot/#/builders/46/builds/13210 - https://lab.llvm.org/buildbot/#/builders/46/builds/13208 - https://lab.llvm.org/buildbot/#/builders/46/builds/13207 - https://lab.llvm.org/buildbot/#/builders/46/builds/13202 - https://lab.llvm.org/buildbot/#/builders/46/builds/13196 and - https://lab.llvm.org/buildbot/#/builders/180/builds/14266 - https://lab.llvm.org/buildbot/#/builders/180/builds/14254 - https://lab.llvm.org/buildbot/#/builders/180/builds/14250 - https://lab.llvm.org/buildbot/#/builders/180/builds/14245 - https://lab.llvm.org/buildbot/#/builders/180/builds/14244 - https://lab.llvm.org/buildbot/#/builders/180/builds/14226
2025-03-07Modify the localCache API to require an explicit commit on CachedFile… ↵anjenner
(#115331) …Stream. CachedFileStream has previously performed the commit step in its destructor, but this means its only recourse for error handling is report_fatal_error. Modify this to add an explicit commit() method, and call this in the appropriate places with appropriate error handling for the location. Currently the destructor of CacheStream gives an assert failure in Debug builds if commit() was not called. This will help track down any remaining uses of the API that assume the old destructior behaviour. In Release builds we fall back to the previous behaviour and call report_fatal_error if the commit fails.
2024-10-19[lldb] Avoid repeated hash lookups (NFC) (#113024)Kazu Hirata
2023-09-01[lldb] Fix duplicate word typos; NFCFangrui Song
Those fixes were taken from https://reviews.llvm.org/D137338
2022-11-22Reland "[LTO][COFF] Use bitcode file names in lto native object file names."Zequan Wu
This reverts commit 34108082947c964ae9bbfcd9808f2fd31c0d672f with fixes.
2022-11-23Revert "Reland "[LTO][COFF] Use bitcode file names in lto native object file ↵Roman Lebedev
names."" Breaks build of LLVMgold here: ``` /repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1108:19: error: no matching function for call to 'localCache' Cache = check(localCache("ThinLTO", "Thin", options::cache_dir, AddBuffer)); ^~~~~~~~~~ /repositories/llvm-project/llvm/include/llvm/Support/Caching.h:72:21: note: candidate function not viable: no known conversion from '(lambda at /repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1102:20)' to 'llvm::AddBufferFn' (aka 'function<void (unsigned int, const llvm::Twine &, std::unique_ptr<MemoryBuffer>)>') for 4th argument Expected<FileCache> localCache( ^ /repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1110:18: error: no viable conversion from '(lambda at /repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20)' to 'llvm::AddStreamFn' (aka 'function<Expected<std::unique_ptr<CachedFileStream>> (unsigned int, const llvm::Twine &)>') check(Lto->run(AddStream, Cache)); ^~~~~~~~~ /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/std_function.h:375:7: note: candidate constructor not viable: no known conversion from '(lambda at /repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20)' to 'std::nullptr_t' for 1st argument function(nullptr_t) noexcept ^ /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/std_function.h:386:7: note: candidate constructor not viable: no known conversion from '(lambda at /repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20)' to 'const std::function<llvm::Expected<std::unique_ptr<llvm::CachedFileStream>> (unsigned int, const llvm::Twine &)> &' for 1st argument function(const function& __x) ^ /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/std_function.h:404:7: note: candidate constructor not viable: no known conversion from '(lambda at /repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20)' to 'std::function<llvm::Expected<std::unique_ptr<llvm::CachedFileStream>> (unsigned int, const llvm::Twine &)> &&' for 1st argument function(function&& __x) noexcept ^ /usr/bin/../lib/gcc/x86_64-linux-gnu/12/../../../../include/c++/12/bits/std_function.h:435:2: note: candidate template ignored: requirement '_Callable<(lambda at /repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20) &, (lambda at /repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20), std::__invoke_result<(lambda at /repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20) &, unsigned int, const llvm::Twine &>>::value' was not satisfied [with _Functor = (lambda at /repositories/llvm-project/llvm/tools/gold/gold-plugin.cpp:1094:20) &] function(_Functor&& __f) ^ /repositories/llvm-project/llvm/include/llvm/LTO/LTO.h:278:25: note: passing argument to parameter 'AddStream' here Error run(AddStreamFn AddStream, FileCache Cache = nullptr); ^ ``` This reverts commit 387620aa8cea33174b6c1fb80c1af713fee732ac.
2022-11-22Reland "[LTO][COFF] Use bitcode file names in lto native object file names."Zequan Wu
This reverts commit eef5405f74ae208e3e2eb7daacecac923d7338f2.
2022-11-22Revert "[LTO][COFF] Use bitcode file names in lto native object file names."Zequan Wu
This reverts commit 531ed6d5aa65f41c6dfe2e74905d5c6c88fc95a7.
2022-11-22[LTO][COFF] Use bitcode file names in lto native object file names.Zequan Wu
Currently the lto native object files have names like main.exe.lto.1.obj. In PDB, those names are used as names for each compiland. Microsoft’s tool SizeBench uses those names to present to users the size of each object files. So, names like main.exe.lto.1.obj is not user friendly. This patch makes the lto native object file names more readable by using the bitcode file names as part of the file names. For example, if the input bitcode file has path like "path/to/foo.obj", its corresponding lto native object file path would be "path/to/main.exe.lto.foo.obj". Since the lto native object file name only bothers PDB, this patch only changes the lld-linker's behavior. Reviewed By: tejohnson, MaskRay, #lld-macho Differential Revision: https://reviews.llvm.org/D137217
2022-09-19[lldb] Appease the MSCV compilerJonas Devlieghere
Fix error C2027: use of undefined type 'llvm::MemoryBuffer'.
2022-08-30Change the meaning of a UUID with all zeros for data.Jim Ingham
Previously, depending on how you constructed a UUID from data or a StringRef, an input value of all zeros was valid (e.g. setFromData) or not (e.g. setFromOptionalData). Since there was no way to tell which interpretation to use, it was done somewhat inconsistently. This standardizes the meaning of a UUID of all zeros to Not Valid, and removes all the Optional methods and their uses, as well as the static factories that supported them. Differential Revision: https://reviews.llvm.org/D132191
2022-08-11[lldb] Allow DataFileCache to be constructed with a different policyAugusto Noronha
Differential Revision: https://reviews.llvm.org/D131531
2022-06-26[lld] Don't use Optional::hasValue (NFC)Kazu Hirata
This patch replaces x.hasValue() with x where x is contextually convertible to bool.
2022-06-25Revert "Don't use Optional::hasValue (NFC)"Kazu Hirata
This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.
2022-06-25Don't use Optional::hasValue (NFC)Kazu Hirata
2022-04-05Disable LLDB index cache for .o files with no UUID.Greg Clayton
After enabling the LLDB index cache in production we discovered that some distributed build systems play with the modification times of any .o files that were downloaded from the build cache. This was causing the LLDB index cache to read the wrong cache file for files that didn't have a UUID as all of the modfication times were set to the same value by the build system. When new .o files were downloaded, the only unique identifier was the mod time which were all the same, and we would load an older cache for the updated .o file. So disabling caching of files that have no UUIDs for now until we can create a more solid solution. Differential Revision: https://reviews.llvm.org/D120948
2022-03-03[lldb] Fix DataExtractor symbol conflictEmre Kultursay
There are two DataExtractors in scope: one from the llvm namespace and one from the lldb_private namespace. Some Microsoft Visual C++ compilers (I tested with MSVC 14.23 specifically) cannot handle this situation, and generate ambiguous symbol errors. This change fixes this compile error. Differential revision: https://reviews.llvm.org/D120718
2022-02-03[lldb] Rename Logging.h to LLDBLog.h and clean up includesPavel Labath
Most of our code was including Log.h even though that is not where the "lldb" log channel is defined (Log.h defines the generic logging infrastructure). This worked because Log.h included Logging.h, even though it should. After the recent refactor, it became impossible the two files include each other in this direction (the opposite inclusion is needed), so this patch removes the workaround that was put in place and cleans up all files to include the right thing. It also renames the file to LLDBLog to better reflect its purpose.
2022-02-02[lldb] Convert "LLDB" log channel to the new APIPavel Labath
2021-12-17Silence unused variable warning in release buildsBenjamin Kramer
lldb/source/Core/DataFileCache.cpp:278:10: warning: unused variable 'pos' [-Wunused-variable] auto pos = m_string_to_offset.find(s); ^ lldb/source/Core/DataFileCache.cpp:277:18: warning: unused variable 'stroff' [-Wunused-variable] const size_t stroff = encoder.GetByteSize() - strtab_offset; ^
2021-12-16Added the ability to cache the finalized symbol tables subsequent debug ↵Greg Clayton
sessions to start faster. This is an updated version of the https://reviews.llvm.org/D113789 patch with the following changes: - We no longer modify modification times of the cache files - Use LLVM caching and cache pruning instead of making a new cache mechanism (See DataFileCache.h/.cpp) - Add signature to start of each file since we are not using modification times so we can tell when caches are stale and remove and re-create the cache file as files are changed - Add settings to control the cache size, disk percentage and expiration in days to keep cache size under control This patch enables symbol tables to be cached in the LLDB index cache directory. All cache files are in a single directory and the files use unique names to ensure that files from the same path will re-use the same file as files get modified. This means as files change, their cache files will be deleted and updated. The modification time of each of the cache files is not modified so that access based pruning of the cache can be implemented. The symbol table cache files start with a signature that uniquely identifies a file on disk and contains one or more of the following items: - object file UUID if available - object file mod time if available - object name for BSD archive .o files that are in .a files if available If none of these signature items are available, then the file will not be cached. This keeps temporary object files from expressions from being cached. When the cache files are loaded on subsequent debug sessions, the signature is compare and if the file has been modified (uuid changes, mod time changes, or object file mod time changes) then the cache file is deleted and re-created. Module caching must be enabled by the user before this can be used: symbols.enable-lldb-index-cache (boolean) = false (lldb) settings set symbols.enable-lldb-index-cache true There is also a setting that allows the user to specify a module cache directory that defaults to a directory that defaults to being next to the symbols.clang-modules-cache-path directory in a temp directory: (lldb) settings show symbols.lldb-index-cache-path /var/folders/9p/472sr0c55l9b20x2zg36b91h0000gn/C/lldb/IndexCache If this setting is enabled, the finalized symbol tables will be serialized and saved to disc so they can be quickly loaded next time you debug. Each module can cache one or more files in the index cache directory. The cache file names must be unique to a file on disk and its architecture and object name for .o files in BSD archives. This allows universal mach-o files to support caching multuple architectures in the same module cache directory. Making the file based on the this info allows this cache file to be deleted and replaced when the file gets updated on disk. This keeps the cache from growing over time during the compile/edit/debug cycle and prevents out of space issues. If the cache is enabled, the symbol table will be loaded from the cache the next time you debug if the module has not changed. The cache also has settings to control the size of the cache on disk. Each time LLDB starts up with the index cache enable, the cache will be pruned to ensure it stays within the user defined settings: (lldb) settings set symbols.lldb-index-cache-expiration-days <days> A value of zero will disable cache files from expiring when the cache is pruned. The default value is 7 currently. (lldb) settings set symbols.lldb-index-cache-max-byte-size <size> A value of zero will disable pruning based on a total byte size. The default value is zero currently. (lldb) settings set symbols.lldb-index-cache-max-percent <percentage-of-disk-space> A value of 100 will allow the disc to be filled to the max, a value of zero will disable percentage pruning. The default value is zero. Reviewed By: labath, wallace Differential Revision: https://reviews.llvm.org/D115324