Files
llvm/lldb/source/Core/SourceManager.cpp

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

834 lines
27 KiB
C++
Raw Normal View History

//===-- SourceManager.cpp -------------------------------------------------===//
//
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
//
//===----------------------------------------------------------------------===//
#include "lldb/Core/SourceManager.h"
#include "lldb/Core/Address.h"
#include "lldb/Core/AddressRange.h"
#include "lldb/Core/Debugger.h"
#include "lldb/Core/FormatEntity.h"
#include "lldb/Core/Highlighter.h"
<rdar://problem/11757916> Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes: - Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". - modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly - Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was. - modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile() Cleaned up header includes a bit as well. llvm-svn: 162860
2012-08-29 21:13:06 +00:00
#include "lldb/Core/Module.h"
#include "lldb/Core/ModuleList.h"
#include "lldb/Host/FileSystem.h"
<rdar://problem/11757916> Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes: - Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". - modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly - Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was. - modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile() Cleaned up header includes a bit as well. llvm-svn: 162860
2012-08-29 21:13:06 +00:00
#include "lldb/Symbol/CompileUnit.h"
#include "lldb/Symbol/Function.h"
#include "lldb/Symbol/LineEntry.h"
#include "lldb/Symbol/SymbolContext.h"
#include "lldb/Target/PathMappingList.h"
[lldb] Add two-level caching in the source manager We recently saw an uptick in internal reports complaining that LLDB is slow when sources on network file systems are inaccessible. I looked at the SourceManger and its cache and I think there’s some room for improvement in terms of reducing file system accesses: 1. We always resolve the path. 2. We always check the timestamp. 3. We always recheck the file system for negative cache hits. D153726 fixes (1) but (2) and (3) are necessary because of the cache’s current design. Source files are cached at the debugger level which means that the source file cache can span multiple targets and processes. It wouldn't be correct to not reload a modified or new file from disk. We can however significantly reduce the number of file system accesses by using a two level cache design: one cache at the debugger level and one at the process level: - The cache at the debugger level works the way it does today. There is no negative cache: if we can't find the file on disk, we'll try again next time the cache is queried. If a cached file's timestamp changes or if its path remapping changes, the cached file is evicted and we reload it from disk. - The cache at the process level is design to avoid accessing the file system. It doesn't check the file's modification time. It caches negative results, so if a file didn't exist, it doesn't try to reread it from disk. Checking if the path remapping changed is cheap (doesn't involve checking the file system) and is the only way for a file to get evicted from the process cache. The result of this patch is that LLDB will not show you new content if a file is modified or created while a process is running. I would argue that this is what most people would expect, but it is a change from how LLDB behaves today. For an average stop, we query the source cache 4 times. With the current implementation, that's 4 stats to get the modification time, If the file doesn't exist on disk, that's an additional 4 stats. Before D153726, if the path starts with a ~ there are another additional 4 calls to realpath. When debugging sources on a slow (network) file system, this quickly adds up. In addition to the two level caching, this patch also adds a source logging channel and synchronization to the source file cache. The logging was helpful during development and hopefully will help us triage issues in the future. The synchronization isn't a new requirement: as the cache is shared across targets, there is no guarantees that it can't be accessed concurrently. The patch also fixes a bug where we would only set the source remapping ID if the un-remapped file didn't exist, which led to the file getting evicted from the cache on every access. rdar://110787562 Differential revision: https://reviews.llvm.org/D153834
2023-07-03 14:06:57 -07:00
#include "lldb/Target/Process.h"
#include "lldb/Target/Target.h"
#include "lldb/Utility/AnsiTerminal.h"
#include "lldb/Utility/ConstString.h"
#include "lldb/Utility/DataBuffer.h"
[lldb] Add two-level caching in the source manager We recently saw an uptick in internal reports complaining that LLDB is slow when sources on network file systems are inaccessible. I looked at the SourceManger and its cache and I think there’s some room for improvement in terms of reducing file system accesses: 1. We always resolve the path. 2. We always check the timestamp. 3. We always recheck the file system for negative cache hits. D153726 fixes (1) but (2) and (3) are necessary because of the cache’s current design. Source files are cached at the debugger level which means that the source file cache can span multiple targets and processes. It wouldn't be correct to not reload a modified or new file from disk. We can however significantly reduce the number of file system accesses by using a two level cache design: one cache at the debugger level and one at the process level: - The cache at the debugger level works the way it does today. There is no negative cache: if we can't find the file on disk, we'll try again next time the cache is queried. If a cached file's timestamp changes or if its path remapping changes, the cached file is evicted and we reload it from disk. - The cache at the process level is design to avoid accessing the file system. It doesn't check the file's modification time. It caches negative results, so if a file didn't exist, it doesn't try to reread it from disk. Checking if the path remapping changed is cheap (doesn't involve checking the file system) and is the only way for a file to get evicted from the process cache. The result of this patch is that LLDB will not show you new content if a file is modified or created while a process is running. I would argue that this is what most people would expect, but it is a change from how LLDB behaves today. For an average stop, we query the source cache 4 times. With the current implementation, that's 4 stats to get the modification time, If the file doesn't exist on disk, that's an additional 4 stats. Before D153726, if the path starts with a ~ there are another additional 4 calls to realpath. When debugging sources on a slow (network) file system, this quickly adds up. In addition to the two level caching, this patch also adds a source logging channel and synchronization to the source file cache. The logging was helpful during development and hopefully will help us triage issues in the future. The synchronization isn't a new requirement: as the cache is shared across targets, there is no guarantees that it can't be accessed concurrently. The patch also fixes a bug where we would only set the source remapping ID if the un-remapped file didn't exist, which led to the file getting evicted from the cache on every access. rdar://110787562 Differential revision: https://reviews.llvm.org/D153834
2023-07-03 14:06:57 -07:00
#include "lldb/Utility/LLDBLog.h"
#include "lldb/Utility/Log.h"
#include "lldb/Utility/RegularExpression.h"
#include "lldb/Utility/Stream.h"
#include "lldb/lldb-enumerations.h"
#include "llvm/ADT/Twine.h"
#include <memory>
#include <optional>
#include <utility>
#include <cassert>
#include <cstdio>
namespace lldb_private {
class ExecutionContext;
}
namespace lldb_private {
class ValueObject;
}
using namespace lldb;
using namespace lldb_private;
static inline bool is_newline_char(char ch) { return ch == '\n' || ch == '\r'; }
static void resolve_tilde(FileSpec &file_spec) {
if (!FileSystem::Instance().Exists(file_spec) &&
file_spec.GetDirectory() &&
file_spec.GetDirectory().GetCString()[0] == '~') {
FileSystem::Instance().Resolve(file_spec);
}
}
// SourceManager constructor
SourceManager::SourceManager(const TargetSP &target_sp)
: m_last_line(0), m_last_count(0), m_default_set(false),
m_target_wp(target_sp),
m_debugger_wp(target_sp->GetDebugger().shared_from_this()) {}
SourceManager::SourceManager(const DebuggerSP &debugger_sp)
: m_last_line(0), m_last_count(0), m_default_set(false), m_target_wp(),
m_debugger_wp(debugger_sp) {}
// Destructor
SourceManager::~SourceManager() = default;
SourceManager::FileSP SourceManager::GetFile(const FileSpec &file_spec) {
if (!file_spec)
[lldb] Add two-level caching in the source manager We recently saw an uptick in internal reports complaining that LLDB is slow when sources on network file systems are inaccessible. I looked at the SourceManger and its cache and I think there’s some room for improvement in terms of reducing file system accesses: 1. We always resolve the path. 2. We always check the timestamp. 3. We always recheck the file system for negative cache hits. D153726 fixes (1) but (2) and (3) are necessary because of the cache’s current design. Source files are cached at the debugger level which means that the source file cache can span multiple targets and processes. It wouldn't be correct to not reload a modified or new file from disk. We can however significantly reduce the number of file system accesses by using a two level cache design: one cache at the debugger level and one at the process level: - The cache at the debugger level works the way it does today. There is no negative cache: if we can't find the file on disk, we'll try again next time the cache is queried. If a cached file's timestamp changes or if its path remapping changes, the cached file is evicted and we reload it from disk. - The cache at the process level is design to avoid accessing the file system. It doesn't check the file's modification time. It caches negative results, so if a file didn't exist, it doesn't try to reread it from disk. Checking if the path remapping changed is cheap (doesn't involve checking the file system) and is the only way for a file to get evicted from the process cache. The result of this patch is that LLDB will not show you new content if a file is modified or created while a process is running. I would argue that this is what most people would expect, but it is a change from how LLDB behaves today. For an average stop, we query the source cache 4 times. With the current implementation, that's 4 stats to get the modification time, If the file doesn't exist on disk, that's an additional 4 stats. Before D153726, if the path starts with a ~ there are another additional 4 calls to realpath. When debugging sources on a slow (network) file system, this quickly adds up. In addition to the two level caching, this patch also adds a source logging channel and synchronization to the source file cache. The logging was helpful during development and hopefully will help us triage issues in the future. The synchronization isn't a new requirement: as the cache is shared across targets, there is no guarantees that it can't be accessed concurrently. The patch also fixes a bug where we would only set the source remapping ID if the un-remapped file didn't exist, which led to the file getting evicted from the cache on every access. rdar://110787562 Differential revision: https://reviews.llvm.org/D153834
2023-07-03 14:06:57 -07:00
return {};
[lldb] Add two-level caching in the source manager We recently saw an uptick in internal reports complaining that LLDB is slow when sources on network file systems are inaccessible. I looked at the SourceManger and its cache and I think there’s some room for improvement in terms of reducing file system accesses: 1. We always resolve the path. 2. We always check the timestamp. 3. We always recheck the file system for negative cache hits. D153726 fixes (1) but (2) and (3) are necessary because of the cache’s current design. Source files are cached at the debugger level which means that the source file cache can span multiple targets and processes. It wouldn't be correct to not reload a modified or new file from disk. We can however significantly reduce the number of file system accesses by using a two level cache design: one cache at the debugger level and one at the process level: - The cache at the debugger level works the way it does today. There is no negative cache: if we can't find the file on disk, we'll try again next time the cache is queried. If a cached file's timestamp changes or if its path remapping changes, the cached file is evicted and we reload it from disk. - The cache at the process level is design to avoid accessing the file system. It doesn't check the file's modification time. It caches negative results, so if a file didn't exist, it doesn't try to reread it from disk. Checking if the path remapping changed is cheap (doesn't involve checking the file system) and is the only way for a file to get evicted from the process cache. The result of this patch is that LLDB will not show you new content if a file is modified or created while a process is running. I would argue that this is what most people would expect, but it is a change from how LLDB behaves today. For an average stop, we query the source cache 4 times. With the current implementation, that's 4 stats to get the modification time, If the file doesn't exist on disk, that's an additional 4 stats. Before D153726, if the path starts with a ~ there are another additional 4 calls to realpath. When debugging sources on a slow (network) file system, this quickly adds up. In addition to the two level caching, this patch also adds a source logging channel and synchronization to the source file cache. The logging was helpful during development and hopefully will help us triage issues in the future. The synchronization isn't a new requirement: as the cache is shared across targets, there is no guarantees that it can't be accessed concurrently. The patch also fixes a bug where we would only set the source remapping ID if the un-remapped file didn't exist, which led to the file getting evicted from the cache on every access. rdar://110787562 Differential revision: https://reviews.llvm.org/D153834
2023-07-03 14:06:57 -07:00
Log *log = GetLog(LLDBLog::Source);
[lldb] Add two-level caching in the source manager We recently saw an uptick in internal reports complaining that LLDB is slow when sources on network file systems are inaccessible. I looked at the SourceManger and its cache and I think there’s some room for improvement in terms of reducing file system accesses: 1. We always resolve the path. 2. We always check the timestamp. 3. We always recheck the file system for negative cache hits. D153726 fixes (1) but (2) and (3) are necessary because of the cache’s current design. Source files are cached at the debugger level which means that the source file cache can span multiple targets and processes. It wouldn't be correct to not reload a modified or new file from disk. We can however significantly reduce the number of file system accesses by using a two level cache design: one cache at the debugger level and one at the process level: - The cache at the debugger level works the way it does today. There is no negative cache: if we can't find the file on disk, we'll try again next time the cache is queried. If a cached file's timestamp changes or if its path remapping changes, the cached file is evicted and we reload it from disk. - The cache at the process level is design to avoid accessing the file system. It doesn't check the file's modification time. It caches negative results, so if a file didn't exist, it doesn't try to reread it from disk. Checking if the path remapping changed is cheap (doesn't involve checking the file system) and is the only way for a file to get evicted from the process cache. The result of this patch is that LLDB will not show you new content if a file is modified or created while a process is running. I would argue that this is what most people would expect, but it is a change from how LLDB behaves today. For an average stop, we query the source cache 4 times. With the current implementation, that's 4 stats to get the modification time, If the file doesn't exist on disk, that's an additional 4 stats. Before D153726, if the path starts with a ~ there are another additional 4 calls to realpath. When debugging sources on a slow (network) file system, this quickly adds up. In addition to the two level caching, this patch also adds a source logging channel and synchronization to the source file cache. The logging was helpful during development and hopefully will help us triage issues in the future. The synchronization isn't a new requirement: as the cache is shared across targets, there is no guarantees that it can't be accessed concurrently. The patch also fixes a bug where we would only set the source remapping ID if the un-remapped file didn't exist, which led to the file getting evicted from the cache on every access. rdar://110787562 Differential revision: https://reviews.llvm.org/D153834
2023-07-03 14:06:57 -07:00
DebuggerSP debugger_sp(m_debugger_wp.lock());
TargetSP target_sp(m_target_wp.lock());
[lldb] Add two-level caching in the source manager We recently saw an uptick in internal reports complaining that LLDB is slow when sources on network file systems are inaccessible. I looked at the SourceManger and its cache and I think there’s some room for improvement in terms of reducing file system accesses: 1. We always resolve the path. 2. We always check the timestamp. 3. We always recheck the file system for negative cache hits. D153726 fixes (1) but (2) and (3) are necessary because of the cache’s current design. Source files are cached at the debugger level which means that the source file cache can span multiple targets and processes. It wouldn't be correct to not reload a modified or new file from disk. We can however significantly reduce the number of file system accesses by using a two level cache design: one cache at the debugger level and one at the process level: - The cache at the debugger level works the way it does today. There is no negative cache: if we can't find the file on disk, we'll try again next time the cache is queried. If a cached file's timestamp changes or if its path remapping changes, the cached file is evicted and we reload it from disk. - The cache at the process level is design to avoid accessing the file system. It doesn't check the file's modification time. It caches negative results, so if a file didn't exist, it doesn't try to reread it from disk. Checking if the path remapping changed is cheap (doesn't involve checking the file system) and is the only way for a file to get evicted from the process cache. The result of this patch is that LLDB will not show you new content if a file is modified or created while a process is running. I would argue that this is what most people would expect, but it is a change from how LLDB behaves today. For an average stop, we query the source cache 4 times. With the current implementation, that's 4 stats to get the modification time, If the file doesn't exist on disk, that's an additional 4 stats. Before D153726, if the path starts with a ~ there are another additional 4 calls to realpath. When debugging sources on a slow (network) file system, this quickly adds up. In addition to the two level caching, this patch also adds a source logging channel and synchronization to the source file cache. The logging was helpful during development and hopefully will help us triage issues in the future. The synchronization isn't a new requirement: as the cache is shared across targets, there is no guarantees that it can't be accessed concurrently. The patch also fixes a bug where we would only set the source remapping ID if the un-remapped file didn't exist, which led to the file getting evicted from the cache on every access. rdar://110787562 Differential revision: https://reviews.llvm.org/D153834
2023-07-03 14:06:57 -07:00
if (!debugger_sp || !debugger_sp->GetUseSourceCache()) {
LLDB_LOG(log, "Source file caching disabled: creating new source file: {0}",
file_spec);
if (target_sp)
return std::make_shared<File>(file_spec, target_sp);
return std::make_shared<File>(file_spec, debugger_sp);
}
ProcessSP process_sp = target_sp ? target_sp->GetProcessSP() : ProcessSP();
// Check the process source cache first. This is the fast path which avoids
// touching the file system unless the path remapping has changed.
if (process_sp) {
if (FileSP file_sp =
process_sp->GetSourceFileCache().FindSourceFile(file_spec)) {
LLDB_LOG(log, "Found source file in the process cache: {0}", file_spec);
if (file_sp->PathRemappingIsStale()) {
LLDB_LOG(log, "Path remapping is stale: removing file from caches: {0}",
file_spec);
// Remove the file from the debugger and process cache. Otherwise we'll
// hit the same issue again below when querying the debugger cache.
debugger_sp->GetSourceFileCache().RemoveSourceFile(file_sp);
process_sp->GetSourceFileCache().RemoveSourceFile(file_sp);
file_sp.reset();
} else {
return file_sp;
}
}
}
[lldb] Add two-level caching in the source manager We recently saw an uptick in internal reports complaining that LLDB is slow when sources on network file systems are inaccessible. I looked at the SourceManger and its cache and I think there’s some room for improvement in terms of reducing file system accesses: 1. We always resolve the path. 2. We always check the timestamp. 3. We always recheck the file system for negative cache hits. D153726 fixes (1) but (2) and (3) are necessary because of the cache’s current design. Source files are cached at the debugger level which means that the source file cache can span multiple targets and processes. It wouldn't be correct to not reload a modified or new file from disk. We can however significantly reduce the number of file system accesses by using a two level cache design: one cache at the debugger level and one at the process level: - The cache at the debugger level works the way it does today. There is no negative cache: if we can't find the file on disk, we'll try again next time the cache is queried. If a cached file's timestamp changes or if its path remapping changes, the cached file is evicted and we reload it from disk. - The cache at the process level is design to avoid accessing the file system. It doesn't check the file's modification time. It caches negative results, so if a file didn't exist, it doesn't try to reread it from disk. Checking if the path remapping changed is cheap (doesn't involve checking the file system) and is the only way for a file to get evicted from the process cache. The result of this patch is that LLDB will not show you new content if a file is modified or created while a process is running. I would argue that this is what most people would expect, but it is a change from how LLDB behaves today. For an average stop, we query the source cache 4 times. With the current implementation, that's 4 stats to get the modification time, If the file doesn't exist on disk, that's an additional 4 stats. Before D153726, if the path starts with a ~ there are another additional 4 calls to realpath. When debugging sources on a slow (network) file system, this quickly adds up. In addition to the two level caching, this patch also adds a source logging channel and synchronization to the source file cache. The logging was helpful during development and hopefully will help us triage issues in the future. The synchronization isn't a new requirement: as the cache is shared across targets, there is no guarantees that it can't be accessed concurrently. The patch also fixes a bug where we would only set the source remapping ID if the un-remapped file didn't exist, which led to the file getting evicted from the cache on every access. rdar://110787562 Differential revision: https://reviews.llvm.org/D153834
2023-07-03 14:06:57 -07:00
// Cache miss in the process cache. Check the debugger source cache.
FileSP file_sp = debugger_sp->GetSourceFileCache().FindSourceFile(file_spec);
// We found the file in the debugger cache. Check if anything invalidated our
// cache result.
if (file_sp)
[lldb] Add two-level caching in the source manager We recently saw an uptick in internal reports complaining that LLDB is slow when sources on network file systems are inaccessible. I looked at the SourceManger and its cache and I think there’s some room for improvement in terms of reducing file system accesses: 1. We always resolve the path. 2. We always check the timestamp. 3. We always recheck the file system for negative cache hits. D153726 fixes (1) but (2) and (3) are necessary because of the cache’s current design. Source files are cached at the debugger level which means that the source file cache can span multiple targets and processes. It wouldn't be correct to not reload a modified or new file from disk. We can however significantly reduce the number of file system accesses by using a two level cache design: one cache at the debugger level and one at the process level: - The cache at the debugger level works the way it does today. There is no negative cache: if we can't find the file on disk, we'll try again next time the cache is queried. If a cached file's timestamp changes or if its path remapping changes, the cached file is evicted and we reload it from disk. - The cache at the process level is design to avoid accessing the file system. It doesn't check the file's modification time. It caches negative results, so if a file didn't exist, it doesn't try to reread it from disk. Checking if the path remapping changed is cheap (doesn't involve checking the file system) and is the only way for a file to get evicted from the process cache. The result of this patch is that LLDB will not show you new content if a file is modified or created while a process is running. I would argue that this is what most people would expect, but it is a change from how LLDB behaves today. For an average stop, we query the source cache 4 times. With the current implementation, that's 4 stats to get the modification time, If the file doesn't exist on disk, that's an additional 4 stats. Before D153726, if the path starts with a ~ there are another additional 4 calls to realpath. When debugging sources on a slow (network) file system, this quickly adds up. In addition to the two level caching, this patch also adds a source logging channel and synchronization to the source file cache. The logging was helpful during development and hopefully will help us triage issues in the future. The synchronization isn't a new requirement: as the cache is shared across targets, there is no guarantees that it can't be accessed concurrently. The patch also fixes a bug where we would only set the source remapping ID if the un-remapped file didn't exist, which led to the file getting evicted from the cache on every access. rdar://110787562 Differential revision: https://reviews.llvm.org/D153834
2023-07-03 14:06:57 -07:00
LLDB_LOG(log, "Found source file in the debugger cache: {0}", file_spec);
// Check if the path remapping has changed.
if (file_sp && file_sp->PathRemappingIsStale()) {
LLDB_LOG(log, "Path remapping is stale: {0}", file_spec);
file_sp.reset();
}
// Check if the modification time has changed.
if (file_sp && file_sp->ModificationTimeIsStale()) {
LLDB_LOG(log, "Modification time is stale: {0}", file_spec);
file_sp.reset();
}
// Check if the file exists on disk.
if (file_sp && !FileSystem::Instance().Exists(file_sp->GetFileSpec())) {
LLDB_LOG(log, "File doesn't exist on disk: {0}", file_spec);
file_sp.reset();
}
[lldb] Add two-level caching in the source manager We recently saw an uptick in internal reports complaining that LLDB is slow when sources on network file systems are inaccessible. I looked at the SourceManger and its cache and I think there’s some room for improvement in terms of reducing file system accesses: 1. We always resolve the path. 2. We always check the timestamp. 3. We always recheck the file system for negative cache hits. D153726 fixes (1) but (2) and (3) are necessary because of the cache’s current design. Source files are cached at the debugger level which means that the source file cache can span multiple targets and processes. It wouldn't be correct to not reload a modified or new file from disk. We can however significantly reduce the number of file system accesses by using a two level cache design: one cache at the debugger level and one at the process level: - The cache at the debugger level works the way it does today. There is no negative cache: if we can't find the file on disk, we'll try again next time the cache is queried. If a cached file's timestamp changes or if its path remapping changes, the cached file is evicted and we reload it from disk. - The cache at the process level is design to avoid accessing the file system. It doesn't check the file's modification time. It caches negative results, so if a file didn't exist, it doesn't try to reread it from disk. Checking if the path remapping changed is cheap (doesn't involve checking the file system) and is the only way for a file to get evicted from the process cache. The result of this patch is that LLDB will not show you new content if a file is modified or created while a process is running. I would argue that this is what most people would expect, but it is a change from how LLDB behaves today. For an average stop, we query the source cache 4 times. With the current implementation, that's 4 stats to get the modification time, If the file doesn't exist on disk, that's an additional 4 stats. Before D153726, if the path starts with a ~ there are another additional 4 calls to realpath. When debugging sources on a slow (network) file system, this quickly adds up. In addition to the two level caching, this patch also adds a source logging channel and synchronization to the source file cache. The logging was helpful during development and hopefully will help us triage issues in the future. The synchronization isn't a new requirement: as the cache is shared across targets, there is no guarantees that it can't be accessed concurrently. The patch also fixes a bug where we would only set the source remapping ID if the un-remapped file didn't exist, which led to the file getting evicted from the cache on every access. rdar://110787562 Differential revision: https://reviews.llvm.org/D153834
2023-07-03 14:06:57 -07:00
// If at this point we don't have a valid file, it means we either didn't find
// it in the debugger cache or something caused it to be invalidated.
if (!file_sp) {
LLDB_LOG(log, "Creating and caching new source file: {0}", file_spec);
// (Re)create the file.
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-21 20:13:14 +00:00
if (target_sp)
[lldb] Add two-level caching in the source manager We recently saw an uptick in internal reports complaining that LLDB is slow when sources on network file systems are inaccessible. I looked at the SourceManger and its cache and I think there’s some room for improvement in terms of reducing file system accesses: 1. We always resolve the path. 2. We always check the timestamp. 3. We always recheck the file system for negative cache hits. D153726 fixes (1) but (2) and (3) are necessary because of the cache’s current design. Source files are cached at the debugger level which means that the source file cache can span multiple targets and processes. It wouldn't be correct to not reload a modified or new file from disk. We can however significantly reduce the number of file system accesses by using a two level cache design: one cache at the debugger level and one at the process level: - The cache at the debugger level works the way it does today. There is no negative cache: if we can't find the file on disk, we'll try again next time the cache is queried. If a cached file's timestamp changes or if its path remapping changes, the cached file is evicted and we reload it from disk. - The cache at the process level is design to avoid accessing the file system. It doesn't check the file's modification time. It caches negative results, so if a file didn't exist, it doesn't try to reread it from disk. Checking if the path remapping changed is cheap (doesn't involve checking the file system) and is the only way for a file to get evicted from the process cache. The result of this patch is that LLDB will not show you new content if a file is modified or created while a process is running. I would argue that this is what most people would expect, but it is a change from how LLDB behaves today. For an average stop, we query the source cache 4 times. With the current implementation, that's 4 stats to get the modification time, If the file doesn't exist on disk, that's an additional 4 stats. Before D153726, if the path starts with a ~ there are another additional 4 calls to realpath. When debugging sources on a slow (network) file system, this quickly adds up. In addition to the two level caching, this patch also adds a source logging channel and synchronization to the source file cache. The logging was helpful during development and hopefully will help us triage issues in the future. The synchronization isn't a new requirement: as the cache is shared across targets, there is no guarantees that it can't be accessed concurrently. The patch also fixes a bug where we would only set the source remapping ID if the un-remapped file didn't exist, which led to the file getting evicted from the cache on every access. rdar://110787562 Differential revision: https://reviews.llvm.org/D153834
2023-07-03 14:06:57 -07:00
file_sp = std::make_shared<File>(file_spec, target_sp);
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-21 20:13:14 +00:00
else
file_sp = std::make_shared<File>(file_spec, debugger_sp);
[lldb] Add two-level caching in the source manager We recently saw an uptick in internal reports complaining that LLDB is slow when sources on network file systems are inaccessible. I looked at the SourceManger and its cache and I think there’s some room for improvement in terms of reducing file system accesses: 1. We always resolve the path. 2. We always check the timestamp. 3. We always recheck the file system for negative cache hits. D153726 fixes (1) but (2) and (3) are necessary because of the cache’s current design. Source files are cached at the debugger level which means that the source file cache can span multiple targets and processes. It wouldn't be correct to not reload a modified or new file from disk. We can however significantly reduce the number of file system accesses by using a two level cache design: one cache at the debugger level and one at the process level: - The cache at the debugger level works the way it does today. There is no negative cache: if we can't find the file on disk, we'll try again next time the cache is queried. If a cached file's timestamp changes or if its path remapping changes, the cached file is evicted and we reload it from disk. - The cache at the process level is design to avoid accessing the file system. It doesn't check the file's modification time. It caches negative results, so if a file didn't exist, it doesn't try to reread it from disk. Checking if the path remapping changed is cheap (doesn't involve checking the file system) and is the only way for a file to get evicted from the process cache. The result of this patch is that LLDB will not show you new content if a file is modified or created while a process is running. I would argue that this is what most people would expect, but it is a change from how LLDB behaves today. For an average stop, we query the source cache 4 times. With the current implementation, that's 4 stats to get the modification time, If the file doesn't exist on disk, that's an additional 4 stats. Before D153726, if the path starts with a ~ there are another additional 4 calls to realpath. When debugging sources on a slow (network) file system, this quickly adds up. In addition to the two level caching, this patch also adds a source logging channel and synchronization to the source file cache. The logging was helpful during development and hopefully will help us triage issues in the future. The synchronization isn't a new requirement: as the cache is shared across targets, there is no guarantees that it can't be accessed concurrently. The patch also fixes a bug where we would only set the source remapping ID if the un-remapped file didn't exist, which led to the file getting evicted from the cache on every access. rdar://110787562 Differential revision: https://reviews.llvm.org/D153834
2023-07-03 14:06:57 -07:00
// Add the file to the debugger and process cache. If the file was
// invalidated, this will overwrite it.
debugger_sp->GetSourceFileCache().AddSourceFile(file_spec, file_sp);
if (process_sp)
process_sp->GetSourceFileCache().AddSourceFile(file_spec, file_sp);
}
[lldb] Add two-level caching in the source manager We recently saw an uptick in internal reports complaining that LLDB is slow when sources on network file systems are inaccessible. I looked at the SourceManger and its cache and I think there’s some room for improvement in terms of reducing file system accesses: 1. We always resolve the path. 2. We always check the timestamp. 3. We always recheck the file system for negative cache hits. D153726 fixes (1) but (2) and (3) are necessary because of the cache’s current design. Source files are cached at the debugger level which means that the source file cache can span multiple targets and processes. It wouldn't be correct to not reload a modified or new file from disk. We can however significantly reduce the number of file system accesses by using a two level cache design: one cache at the debugger level and one at the process level: - The cache at the debugger level works the way it does today. There is no negative cache: if we can't find the file on disk, we'll try again next time the cache is queried. If a cached file's timestamp changes or if its path remapping changes, the cached file is evicted and we reload it from disk. - The cache at the process level is design to avoid accessing the file system. It doesn't check the file's modification time. It caches negative results, so if a file didn't exist, it doesn't try to reread it from disk. Checking if the path remapping changed is cheap (doesn't involve checking the file system) and is the only way for a file to get evicted from the process cache. The result of this patch is that LLDB will not show you new content if a file is modified or created while a process is running. I would argue that this is what most people would expect, but it is a change from how LLDB behaves today. For an average stop, we query the source cache 4 times. With the current implementation, that's 4 stats to get the modification time, If the file doesn't exist on disk, that's an additional 4 stats. Before D153726, if the path starts with a ~ there are another additional 4 calls to realpath. When debugging sources on a slow (network) file system, this quickly adds up. In addition to the two level caching, this patch also adds a source logging channel and synchronization to the source file cache. The logging was helpful during development and hopefully will help us triage issues in the future. The synchronization isn't a new requirement: as the cache is shared across targets, there is no guarantees that it can't be accessed concurrently. The patch also fixes a bug where we would only set the source remapping ID if the un-remapped file didn't exist, which led to the file getting evicted from the cache on every access. rdar://110787562 Differential revision: https://reviews.llvm.org/D153834
2023-07-03 14:06:57 -07:00
return file_sp;
}
static bool should_highlight_source(DebuggerSP debugger_sp) {
if (!debugger_sp)
return false;
// We don't use ANSI stop column formatting if the debugger doesn't think it
// should be using color.
if (!debugger_sp->GetUseColor())
return false;
return debugger_sp->GetHighlightSource();
}
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-21 20:13:14 +00:00
static bool should_show_stop_column_with_ansi(DebuggerSP debugger_sp) {
// We don't use ANSI stop column formatting if we can't lookup values from
// the debugger.
if (!debugger_sp)
return false;
// We don't use ANSI stop column formatting if the debugger doesn't think it
// should be using color.
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-21 20:13:14 +00:00
if (!debugger_sp->GetUseColor())
return false;
// We only use ANSI stop column formatting if we're either supposed to show
// ANSI where available (which we know we have when we get to this point), or
// if we're only supposed to use ANSI.
const auto value = debugger_sp->GetStopShowColumn();
return ((value == eStopShowColumnAnsiOrCaret) ||
(value == eStopShowColumnAnsi));
}
static bool should_show_stop_column_with_caret(DebuggerSP debugger_sp) {
// We don't use text-based stop column formatting if we can't lookup values
// from the debugger.
if (!debugger_sp)
return false;
// If we're asked to show the first available of ANSI or caret, then we do
// show the caret when ANSI is not available.
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-21 20:13:14 +00:00
const auto value = debugger_sp->GetStopShowColumn();
if ((value == eStopShowColumnAnsiOrCaret) && !debugger_sp->GetUseColor())
return true;
// The only other time we use caret is if we're explicitly asked to show
// caret.
return value == eStopShowColumnCaret;
}
static bool should_show_stop_line_with_ansi(DebuggerSP debugger_sp) {
return debugger_sp && debugger_sp->GetUseColor();
}
size_t SourceManager::DisplaySourceLinesWithLineNumbersUsingLastFile(
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-21 20:13:14 +00:00
uint32_t start_line, uint32_t count, uint32_t curr_line, uint32_t column,
const char *current_line_cstr, Stream *s,
const SymbolContextList *bp_locs) {
if (count == 0)
return 0;
Stream::ByteDelta delta(*s);
if (start_line == 0) {
if (m_last_line != 0 && m_last_line != UINT32_MAX)
start_line = m_last_line + m_last_count;
else
start_line = 1;
}
if (!m_default_set) {
FileSpec tmp_spec;
uint32_t tmp_line;
GetDefaultFileAndLine(tmp_spec, tmp_line);
}
m_last_line = start_line;
m_last_count = count;
if (FileSP last_file_sp = GetLastFile()) {
const uint32_t end_line = start_line + count - 1;
for (uint32_t line = start_line; line <= end_line; ++line) {
if (!last_file_sp->LineIsValid(line)) {
m_last_line = UINT32_MAX;
break;
}
std::string prefix;
if (bp_locs) {
uint32_t bp_count = bp_locs->NumLineEntriesWithLine(line);
if (bp_count > 0)
prefix = llvm::formatv("[{0}]", bp_count);
else
prefix = " ";
}
char buffer[3];
snprintf(buffer, sizeof(buffer), "%2.2s",
(line == curr_line) ? current_line_cstr : "");
std::string current_line_highlight(buffer);
auto debugger_sp = m_debugger_wp.lock();
if (should_show_stop_line_with_ansi(debugger_sp)) {
current_line_highlight = ansi::FormatAnsiTerminalCodes(
(debugger_sp->GetStopShowLineMarkerAnsiPrefix() +
current_line_highlight +
debugger_sp->GetStopShowLineMarkerAnsiSuffix())
.str());
}
s->Printf("%s%s %-4u\t", prefix.c_str(), current_line_highlight.c_str(),
line);
// So far we treated column 0 as a special 'no column value', but
// DisplaySourceLines starts counting columns from 0 (and no column is
// expressed by passing an empty optional).
std::optional<size_t> columnToHighlight;
if (line == curr_line && column)
columnToHighlight = column - 1;
size_t this_line_size =
last_file_sp->DisplaySourceLines(line, columnToHighlight, 0, 0, s);
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-21 20:13:14 +00:00
if (column != 0 && line == curr_line &&
should_show_stop_column_with_caret(debugger_sp)) {
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-21 20:13:14 +00:00
// Display caret cursor.
std::string src_line;
last_file_sp->GetLine(line, src_line);
s->Printf(" \t");
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-21 20:13:14 +00:00
// Insert a space for every non-tab character in the source line.
for (size_t i = 0; i + 1 < column && i < src_line.length(); ++i)
s->PutChar(src_line[i] == '\t' ? '\t' : ' ');
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-21 20:13:14 +00:00
// Now add the caret.
s->Printf("^\n");
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-21 20:13:14 +00:00
}
if (this_line_size == 0) {
m_last_line = UINT32_MAX;
break;
}
}
}
return *delta;
}
size_t SourceManager::DisplaySourceLinesWithLineNumbers(
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-21 20:13:14 +00:00
const FileSpec &file_spec, uint32_t line, uint32_t column,
uint32_t context_before, uint32_t context_after,
const char *current_line_cstr, Stream *s,
const SymbolContextList *bp_locs) {
FileSP file_sp(GetFile(file_spec));
uint32_t start_line;
uint32_t count = context_before + context_after + 1;
if (line > context_before)
start_line = line - context_before;
else
start_line = 1;
FileSP last_file_sp(GetLastFile());
if (last_file_sp.get() != file_sp.get()) {
if (line == 0)
m_last_line = 0;
m_last_file_spec = file_spec;
}
return DisplaySourceLinesWithLineNumbersUsingLastFile(
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-21 20:13:14 +00:00
start_line, count, line, column, current_line_cstr, s, bp_locs);
}
size_t SourceManager::DisplayMoreWithLineNumbers(
Stream *s, uint32_t count, bool reverse, const SymbolContextList *bp_locs) {
// If we get called before anybody has set a default file and line, then try
// to figure it out here.
FileSP last_file_sp(GetLastFile());
const bool have_default_file_line = last_file_sp && m_last_line > 0;
if (!m_default_set) {
FileSpec tmp_spec;
uint32_t tmp_line;
GetDefaultFileAndLine(tmp_spec, tmp_line);
}
if (last_file_sp) {
if (m_last_line == UINT32_MAX)
return 0;
if (reverse && m_last_line == 1)
return 0;
if (count > 0)
m_last_count = count;
else if (m_last_count == 0)
m_last_count = 10;
if (m_last_line > 0) {
if (reverse) {
// If this is the first time we've done a reverse, then back up one
// more time so we end up showing the chunk before the last one we've
// shown:
if (m_last_line > m_last_count)
m_last_line -= m_last_count;
else
m_last_line = 1;
} else if (have_default_file_line)
m_last_line += m_last_count;
} else
m_last_line = 1;
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-21 20:13:14 +00:00
const uint32_t column = 0;
return DisplaySourceLinesWithLineNumbersUsingLastFile(
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-21 20:13:14 +00:00
m_last_line, m_last_count, UINT32_MAX, column, "", s, bp_locs);
}
return 0;
}
bool SourceManager::SetDefaultFileAndLine(const FileSpec &file_spec,
uint32_t line) {
m_default_set = true;
FileSP file_sp(GetFile(file_spec));
if (file_sp) {
m_last_line = line;
m_last_file_spec = file_spec;
return true;
} else {
return false;
}
}
bool SourceManager::GetDefaultFileAndLine(FileSpec &file_spec, uint32_t &line) {
if (FileSP last_file_sp = GetLastFile()) {
file_spec = m_last_file_spec;
line = m_last_line;
return true;
} else if (!m_default_set) {
TargetSP target_sp(m_target_wp.lock());
if (target_sp) {
// If nobody has set the default file and line then try here. If there's
// no executable, then we will try again later when there is one.
// Otherwise, if we can't find it we won't look again, somebody will have
// to set it (for instance when we stop somewhere...)
Module *executable_ptr = target_sp->GetExecutableModulePointer();
if (executable_ptr) {
SymbolContextList sc_list;
ConstString main_name("main");
ModuleFunctionSearchOptions function_options;
function_options.include_symbols =
false; // Force it to be a debug symbol.
function_options.include_inlines = true;
executable_ptr->FindFunctions(main_name, CompilerDeclContext(),
lldb::eFunctionNameTypeBase,
function_options, sc_list);
for (const SymbolContext &sc : sc_list) {
if (sc.function) {
lldb_private::LineEntry line_entry;
if (sc.function->GetAddressRange()
.GetBaseAddress()
.CalculateSymbolContextLineEntry(line_entry)) {
SetDefaultFileAndLine(line_entry.GetFile(), line_entry.line);
file_spec = m_last_file_spec;
line = m_last_line;
return true;
}
}
}
}
}
}
return false;
}
void SourceManager::FindLinesMatchingRegex(FileSpec &file_spec,
RegularExpression &regex,
uint32_t start_line,
uint32_t end_line,
std::vector<uint32_t> &match_lines) {
match_lines.clear();
FileSP file_sp = GetFile(file_spec);
if (!file_sp)
return;
return file_sp->FindLinesMatchingRegex(regex, start_line, end_line,
match_lines);
}
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-21 20:13:14 +00:00
SourceManager::File::File(const FileSpec &file_spec,
lldb::DebuggerSP debugger_sp)
: m_file_spec_orig(file_spec), m_file_spec(), m_mod_time(),
[lldb] Add two-level caching in the source manager We recently saw an uptick in internal reports complaining that LLDB is slow when sources on network file systems are inaccessible. I looked at the SourceManger and its cache and I think there’s some room for improvement in terms of reducing file system accesses: 1. We always resolve the path. 2. We always check the timestamp. 3. We always recheck the file system for negative cache hits. D153726 fixes (1) but (2) and (3) are necessary because of the cache’s current design. Source files are cached at the debugger level which means that the source file cache can span multiple targets and processes. It wouldn't be correct to not reload a modified or new file from disk. We can however significantly reduce the number of file system accesses by using a two level cache design: one cache at the debugger level and one at the process level: - The cache at the debugger level works the way it does today. There is no negative cache: if we can't find the file on disk, we'll try again next time the cache is queried. If a cached file's timestamp changes or if its path remapping changes, the cached file is evicted and we reload it from disk. - The cache at the process level is design to avoid accessing the file system. It doesn't check the file's modification time. It caches negative results, so if a file didn't exist, it doesn't try to reread it from disk. Checking if the path remapping changed is cheap (doesn't involve checking the file system) and is the only way for a file to get evicted from the process cache. The result of this patch is that LLDB will not show you new content if a file is modified or created while a process is running. I would argue that this is what most people would expect, but it is a change from how LLDB behaves today. For an average stop, we query the source cache 4 times. With the current implementation, that's 4 stats to get the modification time, If the file doesn't exist on disk, that's an additional 4 stats. Before D153726, if the path starts with a ~ there are another additional 4 calls to realpath. When debugging sources on a slow (network) file system, this quickly adds up. In addition to the two level caching, this patch also adds a source logging channel and synchronization to the source file cache. The logging was helpful during development and hopefully will help us triage issues in the future. The synchronization isn't a new requirement: as the cache is shared across targets, there is no guarantees that it can't be accessed concurrently. The patch also fixes a bug where we would only set the source remapping ID if the un-remapped file didn't exist, which led to the file getting evicted from the cache on every access. rdar://110787562 Differential revision: https://reviews.llvm.org/D153834
2023-07-03 14:06:57 -07:00
m_debugger_wp(debugger_sp), m_target_wp(TargetSP()) {
CommonInitializer(file_spec, {});
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-21 20:13:14 +00:00
}
[lldb] Add two-level caching in the source manager We recently saw an uptick in internal reports complaining that LLDB is slow when sources on network file systems are inaccessible. I looked at the SourceManger and its cache and I think there’s some room for improvement in terms of reducing file system accesses: 1. We always resolve the path. 2. We always check the timestamp. 3. We always recheck the file system for negative cache hits. D153726 fixes (1) but (2) and (3) are necessary because of the cache’s current design. Source files are cached at the debugger level which means that the source file cache can span multiple targets and processes. It wouldn't be correct to not reload a modified or new file from disk. We can however significantly reduce the number of file system accesses by using a two level cache design: one cache at the debugger level and one at the process level: - The cache at the debugger level works the way it does today. There is no negative cache: if we can't find the file on disk, we'll try again next time the cache is queried. If a cached file's timestamp changes or if its path remapping changes, the cached file is evicted and we reload it from disk. - The cache at the process level is design to avoid accessing the file system. It doesn't check the file's modification time. It caches negative results, so if a file didn't exist, it doesn't try to reread it from disk. Checking if the path remapping changed is cheap (doesn't involve checking the file system) and is the only way for a file to get evicted from the process cache. The result of this patch is that LLDB will not show you new content if a file is modified or created while a process is running. I would argue that this is what most people would expect, but it is a change from how LLDB behaves today. For an average stop, we query the source cache 4 times. With the current implementation, that's 4 stats to get the modification time, If the file doesn't exist on disk, that's an additional 4 stats. Before D153726, if the path starts with a ~ there are another additional 4 calls to realpath. When debugging sources on a slow (network) file system, this quickly adds up. In addition to the two level caching, this patch also adds a source logging channel and synchronization to the source file cache. The logging was helpful during development and hopefully will help us triage issues in the future. The synchronization isn't a new requirement: as the cache is shared across targets, there is no guarantees that it can't be accessed concurrently. The patch also fixes a bug where we would only set the source remapping ID if the un-remapped file didn't exist, which led to the file getting evicted from the cache on every access. rdar://110787562 Differential revision: https://reviews.llvm.org/D153834
2023-07-03 14:06:57 -07:00
SourceManager::File::File(const FileSpec &file_spec, TargetSP target_sp)
: m_file_spec_orig(file_spec), m_file_spec(), m_mod_time(),
[lldb] Add two-level caching in the source manager We recently saw an uptick in internal reports complaining that LLDB is slow when sources on network file systems are inaccessible. I looked at the SourceManger and its cache and I think there’s some room for improvement in terms of reducing file system accesses: 1. We always resolve the path. 2. We always check the timestamp. 3. We always recheck the file system for negative cache hits. D153726 fixes (1) but (2) and (3) are necessary because of the cache’s current design. Source files are cached at the debugger level which means that the source file cache can span multiple targets and processes. It wouldn't be correct to not reload a modified or new file from disk. We can however significantly reduce the number of file system accesses by using a two level cache design: one cache at the debugger level and one at the process level: - The cache at the debugger level works the way it does today. There is no negative cache: if we can't find the file on disk, we'll try again next time the cache is queried. If a cached file's timestamp changes or if its path remapping changes, the cached file is evicted and we reload it from disk. - The cache at the process level is design to avoid accessing the file system. It doesn't check the file's modification time. It caches negative results, so if a file didn't exist, it doesn't try to reread it from disk. Checking if the path remapping changed is cheap (doesn't involve checking the file system) and is the only way for a file to get evicted from the process cache. The result of this patch is that LLDB will not show you new content if a file is modified or created while a process is running. I would argue that this is what most people would expect, but it is a change from how LLDB behaves today. For an average stop, we query the source cache 4 times. With the current implementation, that's 4 stats to get the modification time, If the file doesn't exist on disk, that's an additional 4 stats. Before D153726, if the path starts with a ~ there are another additional 4 calls to realpath. When debugging sources on a slow (network) file system, this quickly adds up. In addition to the two level caching, this patch also adds a source logging channel and synchronization to the source file cache. The logging was helpful during development and hopefully will help us triage issues in the future. The synchronization isn't a new requirement: as the cache is shared across targets, there is no guarantees that it can't be accessed concurrently. The patch also fixes a bug where we would only set the source remapping ID if the un-remapped file didn't exist, which led to the file getting evicted from the cache on every access. rdar://110787562 Differential revision: https://reviews.llvm.org/D153834
2023-07-03 14:06:57 -07:00
m_debugger_wp(target_sp ? target_sp->GetDebugger().shared_from_this()
: DebuggerSP()),
m_target_wp(target_sp) {
CommonInitializer(file_spec, target_sp);
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-21 20:13:14 +00:00
}
void SourceManager::File::CommonInitializer(const FileSpec &file_spec,
[lldb] Add two-level caching in the source manager We recently saw an uptick in internal reports complaining that LLDB is slow when sources on network file systems are inaccessible. I looked at the SourceManger and its cache and I think there’s some room for improvement in terms of reducing file system accesses: 1. We always resolve the path. 2. We always check the timestamp. 3. We always recheck the file system for negative cache hits. D153726 fixes (1) but (2) and (3) are necessary because of the cache’s current design. Source files are cached at the debugger level which means that the source file cache can span multiple targets and processes. It wouldn't be correct to not reload a modified or new file from disk. We can however significantly reduce the number of file system accesses by using a two level cache design: one cache at the debugger level and one at the process level: - The cache at the debugger level works the way it does today. There is no negative cache: if we can't find the file on disk, we'll try again next time the cache is queried. If a cached file's timestamp changes or if its path remapping changes, the cached file is evicted and we reload it from disk. - The cache at the process level is design to avoid accessing the file system. It doesn't check the file's modification time. It caches negative results, so if a file didn't exist, it doesn't try to reread it from disk. Checking if the path remapping changed is cheap (doesn't involve checking the file system) and is the only way for a file to get evicted from the process cache. The result of this patch is that LLDB will not show you new content if a file is modified or created while a process is running. I would argue that this is what most people would expect, but it is a change from how LLDB behaves today. For an average stop, we query the source cache 4 times. With the current implementation, that's 4 stats to get the modification time, If the file doesn't exist on disk, that's an additional 4 stats. Before D153726, if the path starts with a ~ there are another additional 4 calls to realpath. When debugging sources on a slow (network) file system, this quickly adds up. In addition to the two level caching, this patch also adds a source logging channel and synchronization to the source file cache. The logging was helpful during development and hopefully will help us triage issues in the future. The synchronization isn't a new requirement: as the cache is shared across targets, there is no guarantees that it can't be accessed concurrently. The patch also fixes a bug where we would only set the source remapping ID if the un-remapped file didn't exist, which led to the file getting evicted from the cache on every access. rdar://110787562 Differential revision: https://reviews.llvm.org/D153834
2023-07-03 14:06:57 -07:00
TargetSP target_sp) {
// Set the file and update the modification time.
SetFileSpec(file_spec);
[lldb] Add two-level caching in the source manager We recently saw an uptick in internal reports complaining that LLDB is slow when sources on network file systems are inaccessible. I looked at the SourceManger and its cache and I think there’s some room for improvement in terms of reducing file system accesses: 1. We always resolve the path. 2. We always check the timestamp. 3. We always recheck the file system for negative cache hits. D153726 fixes (1) but (2) and (3) are necessary because of the cache’s current design. Source files are cached at the debugger level which means that the source file cache can span multiple targets and processes. It wouldn't be correct to not reload a modified or new file from disk. We can however significantly reduce the number of file system accesses by using a two level cache design: one cache at the debugger level and one at the process level: - The cache at the debugger level works the way it does today. There is no negative cache: if we can't find the file on disk, we'll try again next time the cache is queried. If a cached file's timestamp changes or if its path remapping changes, the cached file is evicted and we reload it from disk. - The cache at the process level is design to avoid accessing the file system. It doesn't check the file's modification time. It caches negative results, so if a file didn't exist, it doesn't try to reread it from disk. Checking if the path remapping changed is cheap (doesn't involve checking the file system) and is the only way for a file to get evicted from the process cache. The result of this patch is that LLDB will not show you new content if a file is modified or created while a process is running. I would argue that this is what most people would expect, but it is a change from how LLDB behaves today. For an average stop, we query the source cache 4 times. With the current implementation, that's 4 stats to get the modification time, If the file doesn't exist on disk, that's an additional 4 stats. Before D153726, if the path starts with a ~ there are another additional 4 calls to realpath. When debugging sources on a slow (network) file system, this quickly adds up. In addition to the two level caching, this patch also adds a source logging channel and synchronization to the source file cache. The logging was helpful during development and hopefully will help us triage issues in the future. The synchronization isn't a new requirement: as the cache is shared across targets, there is no guarantees that it can't be accessed concurrently. The patch also fixes a bug where we would only set the source remapping ID if the un-remapped file didn't exist, which led to the file getting evicted from the cache on every access. rdar://110787562 Differential revision: https://reviews.llvm.org/D153834
2023-07-03 14:06:57 -07:00
// Always update the source map modification ID if we have a target.
if (target_sp)
m_source_map_mod_id = target_sp->GetSourcePathMap().GetModificationID();
// File doesn't exist.
if (m_mod_time == llvm::sys::TimePoint<>()) {
[lldb] Add two-level caching in the source manager We recently saw an uptick in internal reports complaining that LLDB is slow when sources on network file systems are inaccessible. I looked at the SourceManger and its cache and I think there’s some room for improvement in terms of reducing file system accesses: 1. We always resolve the path. 2. We always check the timestamp. 3. We always recheck the file system for negative cache hits. D153726 fixes (1) but (2) and (3) are necessary because of the cache’s current design. Source files are cached at the debugger level which means that the source file cache can span multiple targets and processes. It wouldn't be correct to not reload a modified or new file from disk. We can however significantly reduce the number of file system accesses by using a two level cache design: one cache at the debugger level and one at the process level: - The cache at the debugger level works the way it does today. There is no negative cache: if we can't find the file on disk, we'll try again next time the cache is queried. If a cached file's timestamp changes or if its path remapping changes, the cached file is evicted and we reload it from disk. - The cache at the process level is design to avoid accessing the file system. It doesn't check the file's modification time. It caches negative results, so if a file didn't exist, it doesn't try to reread it from disk. Checking if the path remapping changed is cheap (doesn't involve checking the file system) and is the only way for a file to get evicted from the process cache. The result of this patch is that LLDB will not show you new content if a file is modified or created while a process is running. I would argue that this is what most people would expect, but it is a change from how LLDB behaves today. For an average stop, we query the source cache 4 times. With the current implementation, that's 4 stats to get the modification time, If the file doesn't exist on disk, that's an additional 4 stats. Before D153726, if the path starts with a ~ there are another additional 4 calls to realpath. When debugging sources on a slow (network) file system, this quickly adds up. In addition to the two level caching, this patch also adds a source logging channel and synchronization to the source file cache. The logging was helpful during development and hopefully will help us triage issues in the future. The synchronization isn't a new requirement: as the cache is shared across targets, there is no guarantees that it can't be accessed concurrently. The patch also fixes a bug where we would only set the source remapping ID if the un-remapped file didn't exist, which led to the file getting evicted from the cache on every access. rdar://110787562 Differential revision: https://reviews.llvm.org/D153834
2023-07-03 14:06:57 -07:00
if (target_sp) {
// If this is just a file name, try finding it in the target.
if (!file_spec.GetDirectory() && file_spec.GetFilename()) {
bool check_inlines = false;
SymbolContextList sc_list;
size_t num_matches =
[lldb] Add two-level caching in the source manager We recently saw an uptick in internal reports complaining that LLDB is slow when sources on network file systems are inaccessible. I looked at the SourceManger and its cache and I think there’s some room for improvement in terms of reducing file system accesses: 1. We always resolve the path. 2. We always check the timestamp. 3. We always recheck the file system for negative cache hits. D153726 fixes (1) but (2) and (3) are necessary because of the cache’s current design. Source files are cached at the debugger level which means that the source file cache can span multiple targets and processes. It wouldn't be correct to not reload a modified or new file from disk. We can however significantly reduce the number of file system accesses by using a two level cache design: one cache at the debugger level and one at the process level: - The cache at the debugger level works the way it does today. There is no negative cache: if we can't find the file on disk, we'll try again next time the cache is queried. If a cached file's timestamp changes or if its path remapping changes, the cached file is evicted and we reload it from disk. - The cache at the process level is design to avoid accessing the file system. It doesn't check the file's modification time. It caches negative results, so if a file didn't exist, it doesn't try to reread it from disk. Checking if the path remapping changed is cheap (doesn't involve checking the file system) and is the only way for a file to get evicted from the process cache. The result of this patch is that LLDB will not show you new content if a file is modified or created while a process is running. I would argue that this is what most people would expect, but it is a change from how LLDB behaves today. For an average stop, we query the source cache 4 times. With the current implementation, that's 4 stats to get the modification time, If the file doesn't exist on disk, that's an additional 4 stats. Before D153726, if the path starts with a ~ there are another additional 4 calls to realpath. When debugging sources on a slow (network) file system, this quickly adds up. In addition to the two level caching, this patch also adds a source logging channel and synchronization to the source file cache. The logging was helpful during development and hopefully will help us triage issues in the future. The synchronization isn't a new requirement: as the cache is shared across targets, there is no guarantees that it can't be accessed concurrently. The patch also fixes a bug where we would only set the source remapping ID if the un-remapped file didn't exist, which led to the file getting evicted from the cache on every access. rdar://110787562 Differential revision: https://reviews.llvm.org/D153834
2023-07-03 14:06:57 -07:00
target_sp->GetImages().ResolveSymbolContextForFilePath(
file_spec.GetFilename().AsCString(), 0, check_inlines,
SymbolContextItem(eSymbolContextModule |
eSymbolContextCompUnit),
sc_list);
bool got_multiple = false;
if (num_matches != 0) {
if (num_matches > 1) {
CompileUnit *test_cu = nullptr;
for (const SymbolContext &sc : sc_list) {
if (sc.comp_unit) {
if (test_cu) {
if (test_cu != sc.comp_unit)
got_multiple = true;
break;
} else
test_cu = sc.comp_unit;
}
}
}
if (!got_multiple) {
SymbolContext sc;
sc_list.GetContextAtIndex(0, sc);
if (sc.comp_unit)
SetFileSpec(sc.comp_unit->GetPrimaryFile());
}
}
}
// Try remapping the file if it doesn't exist.
if (!FileSystem::Instance().Exists(m_file_spec)) {
// Check target specific source remappings (i.e., the
// target.source-map setting), then fall back to the module
// specific remapping (i.e., the .dSYM remapping dictionary).
[lldb] Add two-level caching in the source manager We recently saw an uptick in internal reports complaining that LLDB is slow when sources on network file systems are inaccessible. I looked at the SourceManger and its cache and I think there’s some room for improvement in terms of reducing file system accesses: 1. We always resolve the path. 2. We always check the timestamp. 3. We always recheck the file system for negative cache hits. D153726 fixes (1) but (2) and (3) are necessary because of the cache’s current design. Source files are cached at the debugger level which means that the source file cache can span multiple targets and processes. It wouldn't be correct to not reload a modified or new file from disk. We can however significantly reduce the number of file system accesses by using a two level cache design: one cache at the debugger level and one at the process level: - The cache at the debugger level works the way it does today. There is no negative cache: if we can't find the file on disk, we'll try again next time the cache is queried. If a cached file's timestamp changes or if its path remapping changes, the cached file is evicted and we reload it from disk. - The cache at the process level is design to avoid accessing the file system. It doesn't check the file's modification time. It caches negative results, so if a file didn't exist, it doesn't try to reread it from disk. Checking if the path remapping changed is cheap (doesn't involve checking the file system) and is the only way for a file to get evicted from the process cache. The result of this patch is that LLDB will not show you new content if a file is modified or created while a process is running. I would argue that this is what most people would expect, but it is a change from how LLDB behaves today. For an average stop, we query the source cache 4 times. With the current implementation, that's 4 stats to get the modification time, If the file doesn't exist on disk, that's an additional 4 stats. Before D153726, if the path starts with a ~ there are another additional 4 calls to realpath. When debugging sources on a slow (network) file system, this quickly adds up. In addition to the two level caching, this patch also adds a source logging channel and synchronization to the source file cache. The logging was helpful during development and hopefully will help us triage issues in the future. The synchronization isn't a new requirement: as the cache is shared across targets, there is no guarantees that it can't be accessed concurrently. The patch also fixes a bug where we would only set the source remapping ID if the un-remapped file didn't exist, which led to the file getting evicted from the cache on every access. rdar://110787562 Differential revision: https://reviews.llvm.org/D153834
2023-07-03 14:06:57 -07:00
auto remapped = target_sp->GetSourcePathMap().FindFile(m_file_spec);
if (!remapped) {
FileSpec new_spec;
[lldb] Add two-level caching in the source manager We recently saw an uptick in internal reports complaining that LLDB is slow when sources on network file systems are inaccessible. I looked at the SourceManger and its cache and I think there’s some room for improvement in terms of reducing file system accesses: 1. We always resolve the path. 2. We always check the timestamp. 3. We always recheck the file system for negative cache hits. D153726 fixes (1) but (2) and (3) are necessary because of the cache’s current design. Source files are cached at the debugger level which means that the source file cache can span multiple targets and processes. It wouldn't be correct to not reload a modified or new file from disk. We can however significantly reduce the number of file system accesses by using a two level cache design: one cache at the debugger level and one at the process level: - The cache at the debugger level works the way it does today. There is no negative cache: if we can't find the file on disk, we'll try again next time the cache is queried. If a cached file's timestamp changes or if its path remapping changes, the cached file is evicted and we reload it from disk. - The cache at the process level is design to avoid accessing the file system. It doesn't check the file's modification time. It caches negative results, so if a file didn't exist, it doesn't try to reread it from disk. Checking if the path remapping changed is cheap (doesn't involve checking the file system) and is the only way for a file to get evicted from the process cache. The result of this patch is that LLDB will not show you new content if a file is modified or created while a process is running. I would argue that this is what most people would expect, but it is a change from how LLDB behaves today. For an average stop, we query the source cache 4 times. With the current implementation, that's 4 stats to get the modification time, If the file doesn't exist on disk, that's an additional 4 stats. Before D153726, if the path starts with a ~ there are another additional 4 calls to realpath. When debugging sources on a slow (network) file system, this quickly adds up. In addition to the two level caching, this patch also adds a source logging channel and synchronization to the source file cache. The logging was helpful during development and hopefully will help us triage issues in the future. The synchronization isn't a new requirement: as the cache is shared across targets, there is no guarantees that it can't be accessed concurrently. The patch also fixes a bug where we would only set the source remapping ID if the un-remapped file didn't exist, which led to the file getting evicted from the cache on every access. rdar://110787562 Differential revision: https://reviews.llvm.org/D153834
2023-07-03 14:06:57 -07:00
if (target_sp->GetImages().FindSourceFile(m_file_spec, new_spec))
remapped = new_spec;
}
if (remapped)
SetFileSpec(*remapped);
}
}
}
// If the file exists, read in the data.
if (m_mod_time != llvm::sys::TimePoint<>())
m_data_sp = FileSystem::Instance().CreateDataBuffer(m_file_spec);
}
void SourceManager::File::SetFileSpec(FileSpec file_spec) {
resolve_tilde(file_spec);
m_file_spec = std::move(file_spec);
m_mod_time = FileSystem::Instance().GetModificationTime(m_file_spec);
}
uint32_t SourceManager::File::GetLineOffset(uint32_t line) {
if (line == 0)
return UINT32_MAX;
if (line == 1)
return 0;
if (CalculateLineOffsets(line)) {
if (line < m_offsets.size())
return m_offsets[line - 1]; // yes we want "line - 1" in the index
}
return UINT32_MAX;
}
uint32_t SourceManager::File::GetNumLines() {
CalculateLineOffsets();
return m_offsets.size();
}
const char *SourceManager::File::PeekLineData(uint32_t line) {
if (!LineIsValid(line))
return nullptr;
size_t line_offset = GetLineOffset(line);
if (line_offset < m_data_sp->GetByteSize())
return (const char *)m_data_sp->GetBytes() + line_offset;
return nullptr;
}
uint32_t SourceManager::File::GetLineLength(uint32_t line,
bool include_newline_chars) {
if (!LineIsValid(line))
return false;
size_t start_offset = GetLineOffset(line);
size_t end_offset = GetLineOffset(line + 1);
if (end_offset == UINT32_MAX)
end_offset = m_data_sp->GetByteSize();
if (end_offset > start_offset) {
uint32_t length = end_offset - start_offset;
if (!include_newline_chars) {
const char *line_start =
(const char *)m_data_sp->GetBytes() + start_offset;
while (length > 0) {
const char last_char = line_start[length - 1];
if ((last_char == '\r') || (last_char == '\n'))
--length;
else
break;
}
}
return length;
}
return 0;
}
bool SourceManager::File::LineIsValid(uint32_t line) {
if (line == 0)
return false;
if (CalculateLineOffsets(line))
return line < m_offsets.size();
return false;
}
[lldb] Add two-level caching in the source manager We recently saw an uptick in internal reports complaining that LLDB is slow when sources on network file systems are inaccessible. I looked at the SourceManger and its cache and I think there’s some room for improvement in terms of reducing file system accesses: 1. We always resolve the path. 2. We always check the timestamp. 3. We always recheck the file system for negative cache hits. D153726 fixes (1) but (2) and (3) are necessary because of the cache’s current design. Source files are cached at the debugger level which means that the source file cache can span multiple targets and processes. It wouldn't be correct to not reload a modified or new file from disk. We can however significantly reduce the number of file system accesses by using a two level cache design: one cache at the debugger level and one at the process level: - The cache at the debugger level works the way it does today. There is no negative cache: if we can't find the file on disk, we'll try again next time the cache is queried. If a cached file's timestamp changes or if its path remapping changes, the cached file is evicted and we reload it from disk. - The cache at the process level is design to avoid accessing the file system. It doesn't check the file's modification time. It caches negative results, so if a file didn't exist, it doesn't try to reread it from disk. Checking if the path remapping changed is cheap (doesn't involve checking the file system) and is the only way for a file to get evicted from the process cache. The result of this patch is that LLDB will not show you new content if a file is modified or created while a process is running. I would argue that this is what most people would expect, but it is a change from how LLDB behaves today. For an average stop, we query the source cache 4 times. With the current implementation, that's 4 stats to get the modification time, If the file doesn't exist on disk, that's an additional 4 stats. Before D153726, if the path starts with a ~ there are another additional 4 calls to realpath. When debugging sources on a slow (network) file system, this quickly adds up. In addition to the two level caching, this patch also adds a source logging channel and synchronization to the source file cache. The logging was helpful during development and hopefully will help us triage issues in the future. The synchronization isn't a new requirement: as the cache is shared across targets, there is no guarantees that it can't be accessed concurrently. The patch also fixes a bug where we would only set the source remapping ID if the un-remapped file didn't exist, which led to the file getting evicted from the cache on every access. rdar://110787562 Differential revision: https://reviews.llvm.org/D153834
2023-07-03 14:06:57 -07:00
bool SourceManager::File::ModificationTimeIsStale() const {
// TODO: use host API to sign up for file modifications to anything in our
// source cache and only update when we determine a file has been updated.
// For now we check each time we want to display info for the file.
auto curr_mod_time = FileSystem::Instance().GetModificationTime(m_file_spec);
[lldb] Add two-level caching in the source manager We recently saw an uptick in internal reports complaining that LLDB is slow when sources on network file systems are inaccessible. I looked at the SourceManger and its cache and I think there’s some room for improvement in terms of reducing file system accesses: 1. We always resolve the path. 2. We always check the timestamp. 3. We always recheck the file system for negative cache hits. D153726 fixes (1) but (2) and (3) are necessary because of the cache’s current design. Source files are cached at the debugger level which means that the source file cache can span multiple targets and processes. It wouldn't be correct to not reload a modified or new file from disk. We can however significantly reduce the number of file system accesses by using a two level cache design: one cache at the debugger level and one at the process level: - The cache at the debugger level works the way it does today. There is no negative cache: if we can't find the file on disk, we'll try again next time the cache is queried. If a cached file's timestamp changes or if its path remapping changes, the cached file is evicted and we reload it from disk. - The cache at the process level is design to avoid accessing the file system. It doesn't check the file's modification time. It caches negative results, so if a file didn't exist, it doesn't try to reread it from disk. Checking if the path remapping changed is cheap (doesn't involve checking the file system) and is the only way for a file to get evicted from the process cache. The result of this patch is that LLDB will not show you new content if a file is modified or created while a process is running. I would argue that this is what most people would expect, but it is a change from how LLDB behaves today. For an average stop, we query the source cache 4 times. With the current implementation, that's 4 stats to get the modification time, If the file doesn't exist on disk, that's an additional 4 stats. Before D153726, if the path starts with a ~ there are another additional 4 calls to realpath. When debugging sources on a slow (network) file system, this quickly adds up. In addition to the two level caching, this patch also adds a source logging channel and synchronization to the source file cache. The logging was helpful during development and hopefully will help us triage issues in the future. The synchronization isn't a new requirement: as the cache is shared across targets, there is no guarantees that it can't be accessed concurrently. The patch also fixes a bug where we would only set the source remapping ID if the un-remapped file didn't exist, which led to the file getting evicted from the cache on every access. rdar://110787562 Differential revision: https://reviews.llvm.org/D153834
2023-07-03 14:06:57 -07:00
return curr_mod_time != llvm::sys::TimePoint<>() &&
m_mod_time != curr_mod_time;
}
[lldb] Add two-level caching in the source manager We recently saw an uptick in internal reports complaining that LLDB is slow when sources on network file systems are inaccessible. I looked at the SourceManger and its cache and I think there’s some room for improvement in terms of reducing file system accesses: 1. We always resolve the path. 2. We always check the timestamp. 3. We always recheck the file system for negative cache hits. D153726 fixes (1) but (2) and (3) are necessary because of the cache’s current design. Source files are cached at the debugger level which means that the source file cache can span multiple targets and processes. It wouldn't be correct to not reload a modified or new file from disk. We can however significantly reduce the number of file system accesses by using a two level cache design: one cache at the debugger level and one at the process level: - The cache at the debugger level works the way it does today. There is no negative cache: if we can't find the file on disk, we'll try again next time the cache is queried. If a cached file's timestamp changes or if its path remapping changes, the cached file is evicted and we reload it from disk. - The cache at the process level is design to avoid accessing the file system. It doesn't check the file's modification time. It caches negative results, so if a file didn't exist, it doesn't try to reread it from disk. Checking if the path remapping changed is cheap (doesn't involve checking the file system) and is the only way for a file to get evicted from the process cache. The result of this patch is that LLDB will not show you new content if a file is modified or created while a process is running. I would argue that this is what most people would expect, but it is a change from how LLDB behaves today. For an average stop, we query the source cache 4 times. With the current implementation, that's 4 stats to get the modification time, If the file doesn't exist on disk, that's an additional 4 stats. Before D153726, if the path starts with a ~ there are another additional 4 calls to realpath. When debugging sources on a slow (network) file system, this quickly adds up. In addition to the two level caching, this patch also adds a source logging channel and synchronization to the source file cache. The logging was helpful during development and hopefully will help us triage issues in the future. The synchronization isn't a new requirement: as the cache is shared across targets, there is no guarantees that it can't be accessed concurrently. The patch also fixes a bug where we would only set the source remapping ID if the un-remapped file didn't exist, which led to the file getting evicted from the cache on every access. rdar://110787562 Differential revision: https://reviews.llvm.org/D153834
2023-07-03 14:06:57 -07:00
bool SourceManager::File::PathRemappingIsStale() const {
if (TargetSP target_sp = m_target_wp.lock())
return GetSourceMapModificationID() !=
target_sp->GetSourcePathMap().GetModificationID();
return false;
}
size_t SourceManager::File::DisplaySourceLines(uint32_t line,
std::optional<size_t> column,
uint32_t context_before,
uint32_t context_after,
Stream *s) {
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-21 20:13:14 +00:00
// Nothing to write if there's no stream.
if (!s)
return 0;
// Sanity check m_data_sp before proceeding.
if (!m_data_sp)
return 0;
size_t bytes_written = s->GetWrittenBytes();
auto debugger_sp = m_debugger_wp.lock();
HighlightStyle style;
// Use the default Vim style if source highlighting is enabled.
if (should_highlight_source(debugger_sp))
style = HighlightStyle::MakeVimStyle();
// If we should mark the stop column with color codes, then copy the prefix
// and suffix to our color style.
if (should_show_stop_column_with_ansi(debugger_sp))
style.selected.Set(debugger_sp->GetStopShowColumnAnsiPrefix(),
debugger_sp->GetStopShowColumnAnsiSuffix());
HighlighterManager mgr;
std::string path = GetFileSpec().GetPath(/*denormalize*/ false);
// FIXME: Find a way to get the definitive language this file was written in
// and pass it to the highlighter.
const auto &h = mgr.getHighlighterFor(lldb::eLanguageTypeUnknown, path);
const uint32_t start_line =
line <= context_before ? 1 : line - context_before;
const uint32_t start_line_offset = GetLineOffset(start_line);
if (start_line_offset != UINT32_MAX) {
const uint32_t end_line = line + context_after;
uint32_t end_line_offset = GetLineOffset(end_line + 1);
if (end_line_offset == UINT32_MAX)
end_line_offset = m_data_sp->GetByteSize();
assert(start_line_offset <= end_line_offset);
if (start_line_offset < end_line_offset) {
size_t count = end_line_offset - start_line_offset;
const uint8_t *cstr = m_data_sp->GetBytes() + start_line_offset;
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-21 20:13:14 +00:00
auto ref = llvm::StringRef(reinterpret_cast<const char *>(cstr), count);
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-21 20:13:14 +00:00
h.Highlight(style, ref, column, "", *s);
add stop column highlighting support This change introduces optional marking of the column within a source line where a thread is stopped. This marking will show up when the source code for a thread stop is displayed, when the debug info knows the column information, and if the optional column marking is enabled. There are two separate methods for handling the marking of the stop column: * via ANSI terminal codes, which are added inline to the source line display. The default ANSI mark-up is to underline the column. * via a pure text-based caret that is added in the appropriate column in a newly-inserted blank line underneath the source line in question. There are some new options that control how this all works. * settings set stop-show-column This takes one of 4 values: * ansi-or-caret: use the ANSI terminal code mechanism if LLDB is running with color enabled; if not, use the caret-based, pure text method (see the "caret" mode below). * ansi: only use the ANSI terminal code mechanism to highlight the stop line. If LLDB is running with color disabled, no stop column marking will occur. * caret: only use the pure text caret method, which introduces a newly-inserted line underneath the current line, where the only character in the new line is a caret that highlights the stop column in question. * none: no stop column marking will be attempted. * settings set stop-show-column-ansi-prefix This is a text format that indicates the ANSI formatting code to insert into the stream immediately preceding the column where the stop column character will be marked up. It defaults to ${ansi.underline}; however, it can contain any valid LLDB format codes, e.g. ${ansi.fg.red}${ansi.bold}${ansi.underline} * settings set stop-show-column-ansi-suffix This is the text format that specifies the ANSI terminal codes to end the markup that was started with the prefix described above. It defaults to: ${ansi.normal}. This should be sufficient for the common cases. Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!) differential review: https://reviews.llvm.org/D20835 reviewers: clayborg, jingham llvm-svn: 282105
2016-09-21 20:13:14 +00:00
// Ensure we get an end of line character one way or another.
if (!is_newline_char(ref.back()))
s->EOL();
}
}
return s->GetWrittenBytes() - bytes_written;
}
void SourceManager::File::FindLinesMatchingRegex(
RegularExpression &regex, uint32_t start_line, uint32_t end_line,
std::vector<uint32_t> &match_lines) {
match_lines.clear();
if (!LineIsValid(start_line) ||
(end_line != UINT32_MAX && !LineIsValid(end_line)))
return;
if (start_line > end_line)
return;
for (uint32_t line_no = start_line; line_no < end_line; line_no++) {
std::string buffer;
if (!GetLine(line_no, buffer))
break;
if (regex.Execute(buffer)) {
match_lines.push_back(line_no);
}
}
}
bool lldb_private::operator==(const SourceManager::File &lhs,
const SourceManager::File &rhs) {
if (lhs.m_file_spec != rhs.m_file_spec)
return false;
return lhs.m_mod_time == rhs.m_mod_time;
}
bool SourceManager::File::CalculateLineOffsets(uint32_t line) {
line =
UINT32_MAX; // TODO: take this line out when we support partial indexing
if (line == UINT32_MAX) {
// Already done?
if (!m_offsets.empty() && m_offsets[0] == UINT32_MAX)
return true;
if (m_offsets.empty()) {
if (m_data_sp.get() == nullptr)
return false;
const char *start = (const char *)m_data_sp->GetBytes();
if (start) {
const char *end = start + m_data_sp->GetByteSize();
// Calculate all line offsets from scratch
// Push a 1 at index zero to indicate the file has been completely
// indexed.
m_offsets.push_back(UINT32_MAX);
const char *s;
for (s = start; s < end; ++s) {
char curr_ch = *s;
if (is_newline_char(curr_ch)) {
if (s + 1 < end) {
char next_ch = s[1];
if (is_newline_char(next_ch)) {
if (curr_ch != next_ch)
++s;
}
}
m_offsets.push_back(s + 1 - start);
}
}
if (!m_offsets.empty()) {
if (m_offsets.back() < size_t(end - start))
m_offsets.push_back(end - start);
}
return true;
}
} else {
// Some lines have been populated, start where we last left off
assert("Not implemented yet" && false);
}
} else {
// Calculate all line offsets up to "line"
assert("Not implemented yet" && false);
}
return false;
}
bool SourceManager::File::GetLine(uint32_t line_no, std::string &buffer) {
if (!LineIsValid(line_no))
return false;
size_t start_offset = GetLineOffset(line_no);
size_t end_offset = GetLineOffset(line_no + 1);
if (end_offset == UINT32_MAX) {
end_offset = m_data_sp->GetByteSize();
}
buffer.assign((const char *)m_data_sp->GetBytes() + start_offset,
end_offset - start_offset);
return true;
}
void SourceManager::SourceFileCache::AddSourceFile(const FileSpec &file_spec,
FileSP file_sp) {
[lldb] Add two-level caching in the source manager We recently saw an uptick in internal reports complaining that LLDB is slow when sources on network file systems are inaccessible. I looked at the SourceManger and its cache and I think there’s some room for improvement in terms of reducing file system accesses: 1. We always resolve the path. 2. We always check the timestamp. 3. We always recheck the file system for negative cache hits. D153726 fixes (1) but (2) and (3) are necessary because of the cache’s current design. Source files are cached at the debugger level which means that the source file cache can span multiple targets and processes. It wouldn't be correct to not reload a modified or new file from disk. We can however significantly reduce the number of file system accesses by using a two level cache design: one cache at the debugger level and one at the process level: - The cache at the debugger level works the way it does today. There is no negative cache: if we can't find the file on disk, we'll try again next time the cache is queried. If a cached file's timestamp changes or if its path remapping changes, the cached file is evicted and we reload it from disk. - The cache at the process level is design to avoid accessing the file system. It doesn't check the file's modification time. It caches negative results, so if a file didn't exist, it doesn't try to reread it from disk. Checking if the path remapping changed is cheap (doesn't involve checking the file system) and is the only way for a file to get evicted from the process cache. The result of this patch is that LLDB will not show you new content if a file is modified or created while a process is running. I would argue that this is what most people would expect, but it is a change from how LLDB behaves today. For an average stop, we query the source cache 4 times. With the current implementation, that's 4 stats to get the modification time, If the file doesn't exist on disk, that's an additional 4 stats. Before D153726, if the path starts with a ~ there are another additional 4 calls to realpath. When debugging sources on a slow (network) file system, this quickly adds up. In addition to the two level caching, this patch also adds a source logging channel and synchronization to the source file cache. The logging was helpful during development and hopefully will help us triage issues in the future. The synchronization isn't a new requirement: as the cache is shared across targets, there is no guarantees that it can't be accessed concurrently. The patch also fixes a bug where we would only set the source remapping ID if the un-remapped file didn't exist, which led to the file getting evicted from the cache on every access. rdar://110787562 Differential revision: https://reviews.llvm.org/D153834
2023-07-03 14:06:57 -07:00
llvm::sys::ScopedWriter guard(m_mutex);
assert(file_sp && "invalid FileSP");
AddSourceFileImpl(file_spec, file_sp);
const FileSpec &resolved_file_spec = file_sp->GetFileSpec();
if (file_spec != resolved_file_spec)
AddSourceFileImpl(file_sp->GetFileSpec(), file_sp);
}
[lldb] Add two-level caching in the source manager We recently saw an uptick in internal reports complaining that LLDB is slow when sources on network file systems are inaccessible. I looked at the SourceManger and its cache and I think there’s some room for improvement in terms of reducing file system accesses: 1. We always resolve the path. 2. We always check the timestamp. 3. We always recheck the file system for negative cache hits. D153726 fixes (1) but (2) and (3) are necessary because of the cache’s current design. Source files are cached at the debugger level which means that the source file cache can span multiple targets and processes. It wouldn't be correct to not reload a modified or new file from disk. We can however significantly reduce the number of file system accesses by using a two level cache design: one cache at the debugger level and one at the process level: - The cache at the debugger level works the way it does today. There is no negative cache: if we can't find the file on disk, we'll try again next time the cache is queried. If a cached file's timestamp changes or if its path remapping changes, the cached file is evicted and we reload it from disk. - The cache at the process level is design to avoid accessing the file system. It doesn't check the file's modification time. It caches negative results, so if a file didn't exist, it doesn't try to reread it from disk. Checking if the path remapping changed is cheap (doesn't involve checking the file system) and is the only way for a file to get evicted from the process cache. The result of this patch is that LLDB will not show you new content if a file is modified or created while a process is running. I would argue that this is what most people would expect, but it is a change from how LLDB behaves today. For an average stop, we query the source cache 4 times. With the current implementation, that's 4 stats to get the modification time, If the file doesn't exist on disk, that's an additional 4 stats. Before D153726, if the path starts with a ~ there are another additional 4 calls to realpath. When debugging sources on a slow (network) file system, this quickly adds up. In addition to the two level caching, this patch also adds a source logging channel and synchronization to the source file cache. The logging was helpful during development and hopefully will help us triage issues in the future. The synchronization isn't a new requirement: as the cache is shared across targets, there is no guarantees that it can't be accessed concurrently. The patch also fixes a bug where we would only set the source remapping ID if the un-remapped file didn't exist, which led to the file getting evicted from the cache on every access. rdar://110787562 Differential revision: https://reviews.llvm.org/D153834
2023-07-03 14:06:57 -07:00
void SourceManager::SourceFileCache::RemoveSourceFile(const FileSP &file_sp) {
llvm::sys::ScopedWriter guard(m_mutex);
assert(file_sp && "invalid FileSP");
// Iterate over all the elements in the cache.
// This is expensive but a relatively uncommon operation.
auto it = m_file_cache.begin();
while (it != m_file_cache.end()) {
if (it->second == file_sp)
it = m_file_cache.erase(it);
else
it++;
}
}
void SourceManager::SourceFileCache::AddSourceFileImpl(
const FileSpec &file_spec, FileSP file_sp) {
FileCache::iterator pos = m_file_cache.find(file_spec);
if (pos == m_file_cache.end()) {
m_file_cache[file_spec] = file_sp;
} else {
if (file_sp != pos->second)
m_file_cache[file_spec] = file_sp;
}
}
SourceManager::FileSP SourceManager::SourceFileCache::FindSourceFile(
const FileSpec &file_spec) const {
[lldb] Add two-level caching in the source manager We recently saw an uptick in internal reports complaining that LLDB is slow when sources on network file systems are inaccessible. I looked at the SourceManger and its cache and I think there’s some room for improvement in terms of reducing file system accesses: 1. We always resolve the path. 2. We always check the timestamp. 3. We always recheck the file system for negative cache hits. D153726 fixes (1) but (2) and (3) are necessary because of the cache’s current design. Source files are cached at the debugger level which means that the source file cache can span multiple targets and processes. It wouldn't be correct to not reload a modified or new file from disk. We can however significantly reduce the number of file system accesses by using a two level cache design: one cache at the debugger level and one at the process level: - The cache at the debugger level works the way it does today. There is no negative cache: if we can't find the file on disk, we'll try again next time the cache is queried. If a cached file's timestamp changes or if its path remapping changes, the cached file is evicted and we reload it from disk. - The cache at the process level is design to avoid accessing the file system. It doesn't check the file's modification time. It caches negative results, so if a file didn't exist, it doesn't try to reread it from disk. Checking if the path remapping changed is cheap (doesn't involve checking the file system) and is the only way for a file to get evicted from the process cache. The result of this patch is that LLDB will not show you new content if a file is modified or created while a process is running. I would argue that this is what most people would expect, but it is a change from how LLDB behaves today. For an average stop, we query the source cache 4 times. With the current implementation, that's 4 stats to get the modification time, If the file doesn't exist on disk, that's an additional 4 stats. Before D153726, if the path starts with a ~ there are another additional 4 calls to realpath. When debugging sources on a slow (network) file system, this quickly adds up. In addition to the two level caching, this patch also adds a source logging channel and synchronization to the source file cache. The logging was helpful during development and hopefully will help us triage issues in the future. The synchronization isn't a new requirement: as the cache is shared across targets, there is no guarantees that it can't be accessed concurrently. The patch also fixes a bug where we would only set the source remapping ID if the un-remapped file didn't exist, which led to the file getting evicted from the cache on every access. rdar://110787562 Differential revision: https://reviews.llvm.org/D153834
2023-07-03 14:06:57 -07:00
llvm::sys::ScopedReader guard(m_mutex);
FileCache::const_iterator pos = m_file_cache.find(file_spec);
if (pos != m_file_cache.end())
[lldb] Add two-level caching in the source manager We recently saw an uptick in internal reports complaining that LLDB is slow when sources on network file systems are inaccessible. I looked at the SourceManger and its cache and I think there’s some room for improvement in terms of reducing file system accesses: 1. We always resolve the path. 2. We always check the timestamp. 3. We always recheck the file system for negative cache hits. D153726 fixes (1) but (2) and (3) are necessary because of the cache’s current design. Source files are cached at the debugger level which means that the source file cache can span multiple targets and processes. It wouldn't be correct to not reload a modified or new file from disk. We can however significantly reduce the number of file system accesses by using a two level cache design: one cache at the debugger level and one at the process level: - The cache at the debugger level works the way it does today. There is no negative cache: if we can't find the file on disk, we'll try again next time the cache is queried. If a cached file's timestamp changes or if its path remapping changes, the cached file is evicted and we reload it from disk. - The cache at the process level is design to avoid accessing the file system. It doesn't check the file's modification time. It caches negative results, so if a file didn't exist, it doesn't try to reread it from disk. Checking if the path remapping changed is cheap (doesn't involve checking the file system) and is the only way for a file to get evicted from the process cache. The result of this patch is that LLDB will not show you new content if a file is modified or created while a process is running. I would argue that this is what most people would expect, but it is a change from how LLDB behaves today. For an average stop, we query the source cache 4 times. With the current implementation, that's 4 stats to get the modification time, If the file doesn't exist on disk, that's an additional 4 stats. Before D153726, if the path starts with a ~ there are another additional 4 calls to realpath. When debugging sources on a slow (network) file system, this quickly adds up. In addition to the two level caching, this patch also adds a source logging channel and synchronization to the source file cache. The logging was helpful during development and hopefully will help us triage issues in the future. The synchronization isn't a new requirement: as the cache is shared across targets, there is no guarantees that it can't be accessed concurrently. The patch also fixes a bug where we would only set the source remapping ID if the un-remapped file didn't exist, which led to the file getting evicted from the cache on every access. rdar://110787562 Differential revision: https://reviews.llvm.org/D153834
2023-07-03 14:06:57 -07:00
return pos->second;
return {};
}
void SourceManager::SourceFileCache::Dump(Stream &stream) const {
stream << "Modification time Lines Path\n";
stream << "------------------- -------- --------------------------------\n";
for (auto &entry : m_file_cache) {
if (!entry.second)
continue;
FileSP file = entry.second;
stream.Format("{0:%Y-%m-%d %H:%M:%S} {1,8:d} {2}\n", file->GetTimestamp(),
file->GetNumLines(), entry.first.GetPath());
}
}