[lldb][NFC] Fix all formatting errors in .cpp file headers
Summary:
A *.cpp file header in LLDB (and in LLDB) should like this:
```
//===-- TestUtilities.cpp -------------------------------------------------===//
```
However in LLDB most of our source files have arbitrary changes to this format and
these changes are spreading through LLDB as folks usually just use the existing
source files as templates for their new files (most notably the unnecessary
editor language indicator `-*- C++ -*-` is spreading and in every review
someone is pointing out that this is wrong, resulting in people pointing out that this
is done in the same way in other files).
This patch removes most of these inconsistencies including the editor language indicators,
all the different missing/additional '-' characters, files that center the file name, missing
trailing `===//` (mostly caused by clang-format breaking the line).
Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D73258
2020-01-24 08:23:27 +01:00
|
|
|
//===-- SourceManager.cpp -------------------------------------------------===//
|
2010-06-08 16:52:24 +00:00
|
|
|
//
|
2019-01-19 08:50:56 +00:00
|
|
|
// 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
|
2010-06-08 16:52:24 +00:00
|
|
|
//
|
|
|
|
|
//===----------------------------------------------------------------------===//
|
|
|
|
|
|
|
|
|
|
#include "lldb/Core/SourceManager.h"
|
|
|
|
|
|
2018-11-11 23:16:43 +00:00
|
|
|
#include "lldb/Core/Address.h"
|
|
|
|
|
#include "lldb/Core/AddressRange.h"
|
2011-09-13 00:29:56 +00:00
|
|
|
#include "lldb/Core/Debugger.h"
|
2018-11-11 23:16:43 +00:00
|
|
|
#include "lldb/Core/FormatEntity.h"
|
2018-08-02 00:30:15 +00:00
|
|
|
#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"
|
2018-11-11 23:16:43 +00:00
|
|
|
#include "lldb/Core/ModuleList.h"
|
2016-11-01 16:11:14 +00:00
|
|
|
#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"
|
2018-11-11 23:16:43 +00:00
|
|
|
#include "lldb/Symbol/LineEntry.h"
|
Added a new option to the "source list" command that allows us to see where
line tables specify breakpoints can be set in the source. When dumping the
source, the number of breakpoints that can be set on a source line are shown
as a prefix:
(lldb) source list -f test.c -l1 -c222 -b
1 #include <stdio.h>
2 #include <sys/fcntl.h>
3 #include <unistd.h>
4 int
5 sleep_loop (const int num_secs)
[2] 6 {
7 int i;
[1] 8 for (i=0; i<num_secs; ++i)
9 {
[1] 10 printf("%d of %i - sleep(1);\n", i, num_secs);
[1] 11 sleep(1);
12 }
13 return 0;
[1] 14 }
15
16 int
17 main (int argc, char const* argv[])
[1] 18 {
[1] 19 printf("Process: %i\n\n", getpid());
[1] 20 puts("Press any key to continue..."); getchar();
[1] 21 sleep_loop (20);
22 return 12;
[1] 23 }
Above we can see there are two breakpoints for line 6 and one breakpoint for
lines 8, 10, 11, 14, 18, 19, 20, 21 and 23. All other lines have no line table
entries for them. This helps visualize the data provided in the debug
information without having to manually dump all line tables. It also includes
all inline breakpoint that may result for a given file which can also be very
handy to see.
llvm-svn: 129747
2011-04-19 04:19:37 +00:00
|
|
|
#include "lldb/Symbol/SymbolContext.h"
|
2018-11-11 23:16:43 +00:00
|
|
|
#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"
|
2011-04-23 02:04:55 +00:00
|
|
|
#include "lldb/Target/Target.h"
|
2020-02-24 15:34:58 -08:00
|
|
|
#include "lldb/Utility/AnsiTerminal.h"
|
2018-11-11 23:16:43 +00:00
|
|
|
#include "lldb/Utility/ConstString.h"
|
2017-03-04 01:30:05 +00:00
|
|
|
#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"
|
2017-02-02 21:39:50 +00:00
|
|
|
#include "lldb/Utility/RegularExpression.h"
|
|
|
|
|
#include "lldb/Utility/Stream.h"
|
2018-11-11 23:16:43 +00:00
|
|
|
#include "lldb/lldb-enumerations.h"
|
2017-04-06 21:28:29 +00:00
|
|
|
|
2018-11-11 23:16:43 +00:00
|
|
|
#include "llvm/ADT/Twine.h"
|
2017-04-06 21:28:29 +00:00
|
|
|
|
|
|
|
|
#include <memory>
|
2023-01-07 13:43:00 -08:00
|
|
|
#include <optional>
|
2018-11-11 23:16:43 +00:00
|
|
|
#include <utility>
|
2017-04-06 21:28:29 +00:00
|
|
|
|
2021-05-26 12:19:37 +02:00
|
|
|
#include <cassert>
|
|
|
|
|
#include <cstdio>
|
2017-04-06 21:28:29 +00:00
|
|
|
|
|
|
|
|
namespace lldb_private {
|
|
|
|
|
class ExecutionContext;
|
|
|
|
|
}
|
|
|
|
|
namespace lldb_private {
|
|
|
|
|
class ValueObject;
|
|
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
|
2013-03-19 00:20:55 +00:00
|
|
|
using namespace lldb;
|
2010-06-08 16:52:24 +00:00
|
|
|
using namespace lldb_private;
|
|
|
|
|
|
|
|
|
|
static inline bool is_newline_char(char ch) { return ch == '\n' || ch == '\r'; }
|
|
|
|
|
|
2022-05-26 00:30:12 -07:00
|
|
|
static void resolve_tilde(FileSpec &file_spec) {
|
|
|
|
|
if (!FileSystem::Instance().Exists(file_spec) &&
|
2022-05-26 11:11:43 -07:00
|
|
|
file_spec.GetDirectory() &&
|
2022-05-26 00:30:12 -07:00
|
|
|
file_spec.GetDirectory().GetCString()[0] == '~') {
|
|
|
|
|
FileSystem::Instance().Resolve(file_spec);
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2024-09-11 08:53:07 -07:00
|
|
|
static std::string toString(const Checksum &checksum) {
|
|
|
|
|
if (!checksum)
|
|
|
|
|
return "";
|
|
|
|
|
return std::string(llvm::formatv("{0}", checksum.digest()));
|
|
|
|
|
}
|
|
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
// SourceManager constructor
|
2013-03-19 00:20:55 +00:00
|
|
|
SourceManager::SourceManager(const TargetSP &target_sp)
|
2024-08-30 10:58:32 -07:00
|
|
|
: m_last_support_file_sp(std::make_shared<SupportFile>()), m_last_line(0),
|
|
|
|
|
m_last_count(0), m_default_set(false), m_target_wp(target_sp),
|
2013-03-19 00:20:55 +00:00
|
|
|
m_debugger_wp(target_sp->GetDebugger().shared_from_this()) {}
|
2011-09-13 00:29:56 +00:00
|
|
|
|
2013-03-19 00:20:55 +00:00
|
|
|
SourceManager::SourceManager(const DebuggerSP &debugger_sp)
|
2024-08-30 10:58:32 -07:00
|
|
|
: m_last_support_file_sp(std::make_shared<SupportFile>()), m_last_line(0),
|
|
|
|
|
m_last_count(0), m_default_set(false), m_target_wp(),
|
2020-04-20 16:17:36 +02:00
|
|
|
m_debugger_wp(debugger_sp) {}
|
2010-06-08 16:52:24 +00:00
|
|
|
|
|
|
|
|
// Destructor
|
2021-07-02 11:27:37 -07:00
|
|
|
SourceManager::~SourceManager() = default;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2024-08-30 10:58:32 -07:00
|
|
|
SourceManager::FileSP SourceManager::GetFile(SupportFileSP support_file_sp) {
|
|
|
|
|
assert(support_file_sp && "SupportFileSP must be valid");
|
|
|
|
|
|
|
|
|
|
FileSpec file_spec = support_file_sp->GetSpecOnly();
|
2020-04-20 16:17:36 +02:00
|
|
|
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 {};
|
2016-09-06 20:57:50 +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
|
|
|
Log *log = GetLog(LLDBLog::Source);
|
2016-09-06 20:57:50 +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
|
|
|
DebuggerSP debugger_sp(m_debugger_wp.lock());
|
2013-03-19 00:20:55 +00:00
|
|
|
TargetSP target_sp(m_target_wp.lock());
|
2016-09-06 20:57:50 +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
|
|
|
if (!debugger_sp || !debugger_sp->GetUseSourceCache()) {
|
|
|
|
|
LLDB_LOG(log, "Source file caching disabled: creating new source file: {0}",
|
|
|
|
|
file_spec);
|
|
|
|
|
if (target_sp)
|
2024-08-30 10:58:32 -07:00
|
|
|
return std::make_shared<File>(support_file_sp, target_sp);
|
|
|
|
|
return std::make_shared<File>(support_file_sp, 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
|
|
|
}
|
|
|
|
|
|
|
|
|
|
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;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
}
|
2016-09-06 20:57:50 +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
|
|
|
// 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.
|
2015-07-29 18:37:25 +00:00
|
|
|
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.
|
2024-08-30 07:18:55 -07:00
|
|
|
if (file_sp && !FileSystem::Instance().Exists(
|
|
|
|
|
file_sp->GetSupportFile()->GetSpecOnly())) {
|
[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, "File doesn't exist on disk: {0}", file_spec);
|
|
|
|
|
file_sp.reset();
|
|
|
|
|
}
|
2016-09-06 20:57:50 +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
|
|
|
// 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)
|
2024-08-30 10:58:32 -07:00
|
|
|
file_sp = std::make_shared<File>(support_file_sp, 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
|
2024-08-30 10:58:32 -07:00
|
|
|
file_sp = std::make_shared<File>(support_file_sp, debugger_sp);
|
2016-09-06 20:57:50 +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
|
|
|
// 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);
|
2010-06-08 16:52:24 +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
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
return file_sp;
|
|
|
|
|
}
|
|
|
|
|
|
2018-08-02 00:30:15 +00:00
|
|
|
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;
|
|
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// 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;
|
|
|
|
|
|
2018-04-30 16:49:04 +00:00
|
|
|
// 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;
|
|
|
|
|
}
|
|
|
|
|
|
2020-02-24 15:34:58 -08:00
|
|
|
static bool should_show_stop_line_with_ansi(DebuggerSP debugger_sp) {
|
|
|
|
|
return debugger_sp && debugger_sp->GetUseColor();
|
|
|
|
|
}
|
|
|
|
|
|
2013-03-13 18:25:49 +00:00
|
|
|
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,
|
2013-03-13 18:25:49 +00:00
|
|
|
const char *current_line_cstr, Stream *s,
|
|
|
|
|
const SymbolContextList *bp_locs) {
|
|
|
|
|
if (count == 0)
|
|
|
|
|
return 0;
|
2018-09-13 09:19:40 +00:00
|
|
|
|
|
|
|
|
Stream::ByteDelta delta(*s);
|
|
|
|
|
|
2013-03-13 18:25:49 +00:00
|
|
|
if (start_line == 0) {
|
|
|
|
|
if (m_last_line != 0 && m_last_line != UINT32_MAX)
|
2013-03-19 00:20:55 +00:00
|
|
|
start_line = m_last_line + m_last_count;
|
2016-09-06 20:57:50 +00:00
|
|
|
else
|
2013-03-13 18:25:49 +00:00
|
|
|
start_line = 1;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2024-08-30 10:58:32 -07:00
|
|
|
if (!m_default_set)
|
|
|
|
|
GetDefaultFileAndLine();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-03-13 18:25:49 +00:00
|
|
|
m_last_line = start_line;
|
|
|
|
|
m_last_count = count;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2020-04-20 16:17:36 +02:00
|
|
|
if (FileSP last_file_sp = GetLastFile()) {
|
2013-03-13 18:25:49 +00:00
|
|
|
const uint32_t end_line = start_line + count - 1;
|
|
|
|
|
for (uint32_t line = start_line; line <= end_line; ++line) {
|
2020-04-20 16:17:36 +02:00
|
|
|
if (!last_file_sp->LineIsValid(line)) {
|
2013-03-13 18:25:49 +00:00
|
|
|
m_last_line = UINT32_MAX;
|
2016-09-06 20:57:50 +00:00
|
|
|
break;
|
|
|
|
|
}
|
|
|
|
|
|
2020-07-27 14:05:23 +02:00
|
|
|
std::string prefix;
|
Added a new option to the "source list" command that allows us to see where
line tables specify breakpoints can be set in the source. When dumping the
source, the number of breakpoints that can be set on a source line are shown
as a prefix:
(lldb) source list -f test.c -l1 -c222 -b
1 #include <stdio.h>
2 #include <sys/fcntl.h>
3 #include <unistd.h>
4 int
5 sleep_loop (const int num_secs)
[2] 6 {
7 int i;
[1] 8 for (i=0; i<num_secs; ++i)
9 {
[1] 10 printf("%d of %i - sleep(1);\n", i, num_secs);
[1] 11 sleep(1);
12 }
13 return 0;
[1] 14 }
15
16 int
17 main (int argc, char const* argv[])
[1] 18 {
[1] 19 printf("Process: %i\n\n", getpid());
[1] 20 puts("Press any key to continue..."); getchar();
[1] 21 sleep_loop (20);
22 return 12;
[1] 23 }
Above we can see there are two breakpoints for line 6 and one breakpoint for
lines 8, 10, 11, 14, 18, 19, 20, 21 and 23. All other lines have no line table
entries for them. This helps visualize the data provided in the debug
information without having to manually dump all line tables. It also includes
all inline breakpoint that may result for a given file which can also be very
handy to see.
llvm-svn: 129747
2011-04-19 04:19:37 +00:00
|
|
|
if (bp_locs) {
|
2013-03-13 18:25:49 +00:00
|
|
|
uint32_t bp_count = bp_locs->NumLineEntriesWithLine(line);
|
2016-09-06 20:57:50 +00:00
|
|
|
|
Added a new option to the "source list" command that allows us to see where
line tables specify breakpoints can be set in the source. When dumping the
source, the number of breakpoints that can be set on a source line are shown
as a prefix:
(lldb) source list -f test.c -l1 -c222 -b
1 #include <stdio.h>
2 #include <sys/fcntl.h>
3 #include <unistd.h>
4 int
5 sleep_loop (const int num_secs)
[2] 6 {
7 int i;
[1] 8 for (i=0; i<num_secs; ++i)
9 {
[1] 10 printf("%d of %i - sleep(1);\n", i, num_secs);
[1] 11 sleep(1);
12 }
13 return 0;
[1] 14 }
15
16 int
17 main (int argc, char const* argv[])
[1] 18 {
[1] 19 printf("Process: %i\n\n", getpid());
[1] 20 puts("Press any key to continue..."); getchar();
[1] 21 sleep_loop (20);
22 return 12;
[1] 23 }
Above we can see there are two breakpoints for line 6 and one breakpoint for
lines 8, 10, 11, 14, 18, 19, 20, 21 and 23. All other lines have no line table
entries for them. This helps visualize the data provided in the debug
information without having to manually dump all line tables. It also includes
all inline breakpoint that may result for a given file which can also be very
handy to see.
llvm-svn: 129747
2011-04-19 04:19:37 +00:00
|
|
|
if (bp_count > 0)
|
2020-07-27 14:05:23 +02:00
|
|
|
prefix = llvm::formatv("[{0}]", bp_count);
|
2010-06-08 16:52:24 +00:00
|
|
|
else
|
2020-07-27 14:05:23 +02:00
|
|
|
prefix = " ";
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
|
2020-02-24 15:34:58 -08:00
|
|
|
char buffer[3];
|
2022-09-24 15:58:03 -07:00
|
|
|
snprintf(buffer, sizeof(buffer), "%2.2s",
|
|
|
|
|
(line == curr_line) ? current_line_cstr : "");
|
2020-02-24 15:34:58 -08:00
|
|
|
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());
|
|
|
|
|
}
|
|
|
|
|
|
2020-07-27 14:05:23 +02:00
|
|
|
s->Printf("%s%s %-4u\t", prefix.c_str(), current_line_highlight.c_str(),
|
|
|
|
|
line);
|
2018-08-30 00:09:21 +00:00
|
|
|
|
|
|
|
|
// 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).
|
2023-01-07 14:18:35 -08:00
|
|
|
std::optional<size_t> columnToHighlight;
|
2018-08-30 00:09:21 +00:00
|
|
|
if (line == curr_line && column)
|
|
|
|
|
columnToHighlight = column - 1;
|
|
|
|
|
|
|
|
|
|
size_t this_line_size =
|
2020-04-20 16:17:36 +02:00
|
|
|
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 &&
|
2020-02-24 15:34:58 -08:00
|
|
|
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;
|
2020-04-20 16:17:36 +02:00
|
|
|
last_file_sp->GetLine(line, src_line);
|
2018-09-13 09:19:40 +00:00
|
|
|
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.
|
2016-09-21 22:36:51 +00:00
|
|
|
for (size_t i = 0; i + 1 < column && i < src_line.length(); ++i)
|
2018-09-13 09:19:40 +00:00
|
|
|
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.
|
2018-09-13 09:19:40 +00:00
|
|
|
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
|
|
|
}
|
2013-03-13 18:25:49 +00:00
|
|
|
if (this_line_size == 0) {
|
|
|
|
|
m_last_line = UINT32_MAX;
|
|
|
|
|
break;
|
2018-09-13 09:19:40 +00:00
|
|
|
}
|
2013-03-13 18:25:49 +00:00
|
|
|
}
|
2024-09-11 08:53:07 -07:00
|
|
|
|
|
|
|
|
Checksum line_table_checksum =
|
|
|
|
|
last_file_sp->GetSupportFile()->GetChecksum();
|
|
|
|
|
Checksum on_disk_checksum = last_file_sp->GetChecksum();
|
|
|
|
|
if (line_table_checksum && line_table_checksum != on_disk_checksum)
|
|
|
|
|
Debugger::ReportWarning(
|
|
|
|
|
llvm::formatv(
|
|
|
|
|
"{0}: source file checksum mismatch between line table "
|
|
|
|
|
"({1}) and file on disk ({2})",
|
|
|
|
|
last_file_sp->GetSupportFile()->GetSpecOnly().GetFilename(),
|
|
|
|
|
toString(line_table_checksum), toString(on_disk_checksum)),
|
|
|
|
|
std::nullopt, &last_file_sp->GetChecksumWarningOnceFlag());
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2018-09-13 09:19:40 +00:00
|
|
|
return *delta;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
|
2013-03-13 18:25:49 +00:00
|
|
|
size_t SourceManager::DisplaySourceLinesWithLineNumbers(
|
2024-08-30 10:58:32 -07:00
|
|
|
lldb::SupportFileSP support_file_sp, uint32_t line, uint32_t column,
|
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 context_before, uint32_t context_after,
|
|
|
|
|
const char *current_line_cstr, Stream *s,
|
2013-03-13 18:25:49 +00:00
|
|
|
const SymbolContextList *bp_locs) {
|
2024-08-30 10:58:32 -07:00
|
|
|
assert(support_file_sp && "SupportFile must be valid");
|
|
|
|
|
FileSP file_sp(GetFile(support_file_sp));
|
2010-06-08 16:52:24 +00:00
|
|
|
|
2013-03-13 18:25:49 +00:00
|
|
|
uint32_t start_line;
|
|
|
|
|
uint32_t count = context_before + context_after + 1;
|
Added a new option to the "source list" command that allows us to see where
line tables specify breakpoints can be set in the source. When dumping the
source, the number of breakpoints that can be set on a source line are shown
as a prefix:
(lldb) source list -f test.c -l1 -c222 -b
1 #include <stdio.h>
2 #include <sys/fcntl.h>
3 #include <unistd.h>
4 int
5 sleep_loop (const int num_secs)
[2] 6 {
7 int i;
[1] 8 for (i=0; i<num_secs; ++i)
9 {
[1] 10 printf("%d of %i - sleep(1);\n", i, num_secs);
[1] 11 sleep(1);
12 }
13 return 0;
[1] 14 }
15
16 int
17 main (int argc, char const* argv[])
[1] 18 {
[1] 19 printf("Process: %i\n\n", getpid());
[1] 20 puts("Press any key to continue..."); getchar();
[1] 21 sleep_loop (20);
22 return 12;
[1] 23 }
Above we can see there are two breakpoints for line 6 and one breakpoint for
lines 8, 10, 11, 14, 18, 19, 20, 21 and 23. All other lines have no line table
entries for them. This helps visualize the data provided in the debug
information without having to manually dump all line tables. It also includes
all inline breakpoint that may result for a given file which can also be very
handy to see.
llvm-svn: 129747
2011-04-19 04:19:37 +00:00
|
|
|
if (line > context_before)
|
|
|
|
|
start_line = line - context_before;
|
|
|
|
|
else
|
|
|
|
|
start_line = 1;
|
|
|
|
|
|
2020-04-20 16:17:36 +02:00
|
|
|
FileSP last_file_sp(GetLastFile());
|
|
|
|
|
if (last_file_sp.get() != file_sp.get()) {
|
2011-09-13 00:29:56 +00:00
|
|
|
if (line == 0)
|
2013-03-13 18:25:49 +00:00
|
|
|
m_last_line = 0;
|
2024-08-30 10:58:32 -07:00
|
|
|
m_last_support_file_sp = support_file_sp;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2024-08-30 10:58:32 -07:00
|
|
|
|
2013-03-13 18:25:49 +00:00
|
|
|
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);
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
2013-03-13 18:25:49 +00:00
|
|
|
size_t SourceManager::DisplayMoreWithLineNumbers(
|
|
|
|
|
Stream *s, uint32_t count, bool reverse, const SymbolContextList *bp_locs) {
|
2013-01-09 03:27:33 +00:00
|
|
|
// If we get called before anybody has set a default file and line, then try
|
|
|
|
|
// to figure it out here.
|
2020-04-20 16:17:36 +02:00
|
|
|
FileSP last_file_sp(GetLastFile());
|
|
|
|
|
const bool have_default_file_line = last_file_sp && m_last_line > 0;
|
2024-08-30 10:58:32 -07:00
|
|
|
if (!m_default_set)
|
|
|
|
|
GetDefaultFileAndLine();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2020-04-20 16:17:36 +02:00
|
|
|
if (last_file_sp) {
|
2025-05-08 22:01:16 +08:00
|
|
|
if (AtLastLine(reverse))
|
2013-01-09 03:27:33 +00:00
|
|
|
return 0;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-03-13 18:25:49 +00:00
|
|
|
if (count > 0)
|
|
|
|
|
m_last_count = count;
|
|
|
|
|
else if (m_last_count == 0)
|
|
|
|
|
m_last_count = 10;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-03-13 18:25:49 +00:00
|
|
|
if (m_last_line > 0) {
|
2013-01-09 03:27:33 +00:00
|
|
|
if (reverse) {
|
2018-04-30 16:49:04 +00:00
|
|
|
// 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:
|
2013-03-13 18:25:49 +00:00
|
|
|
if (m_last_line > m_last_count)
|
|
|
|
|
m_last_line -= m_last_count;
|
2013-01-09 03:27:33 +00:00
|
|
|
else
|
2013-03-13 18:25:49 +00:00
|
|
|
m_last_line = 1;
|
|
|
|
|
} else if (have_default_file_line)
|
|
|
|
|
m_last_line += m_last_count;
|
2016-09-06 20:57:50 +00:00
|
|
|
} else
|
2013-03-13 18:25:49 +00:00
|
|
|
m_last_line = 1;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
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;
|
2013-03-13 18:25:49 +00:00
|
|
|
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);
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2024-08-30 10:58:32 -07:00
|
|
|
bool SourceManager::SetDefaultFileAndLine(lldb::SupportFileSP support_file_sp,
|
2011-09-08 22:13:49 +00:00
|
|
|
uint32_t line) {
|
2024-08-30 10:58:32 -07:00
|
|
|
assert(support_file_sp && "SupportFile must be valid");
|
|
|
|
|
|
2011-10-07 22:16:04 +00:00
|
|
|
m_default_set = true;
|
2020-04-20 16:17:36 +02:00
|
|
|
|
2024-08-30 10:58:32 -07:00
|
|
|
if (FileSP file_sp = GetFile(support_file_sp)) {
|
2013-03-13 18:25:49 +00:00
|
|
|
m_last_line = line;
|
2024-08-30 10:58:32 -07:00
|
|
|
m_last_support_file_sp = support_file_sp;
|
2011-09-08 22:13:49 +00:00
|
|
|
return true;
|
|
|
|
|
}
|
2024-08-30 10:58:32 -07:00
|
|
|
|
|
|
|
|
return false;
|
2011-09-08 22:13:49 +00:00
|
|
|
}
|
|
|
|
|
|
2024-08-30 10:58:32 -07:00
|
|
|
std::optional<SourceManager::SupportFileAndLine>
|
|
|
|
|
SourceManager::GetDefaultFileAndLine() {
|
|
|
|
|
if (FileSP last_file_sp = GetLastFile())
|
|
|
|
|
return SupportFileAndLine(m_last_support_file_sp, m_last_line);
|
|
|
|
|
|
|
|
|
|
if (!m_default_set) {
|
2013-03-19 00:20:55 +00:00
|
|
|
TargetSP target_sp(m_target_wp.lock());
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2013-03-19 00:20:55 +00:00
|
|
|
if (target_sp) {
|
|
|
|
|
// If nobody has set the default file and line then try here. If there's
|
2018-04-30 16:49:04 +00:00
|
|
|
// 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...)
|
2013-03-19 00:20:55 +00:00
|
|
|
Module *executable_ptr = target_sp->GetExecutableModulePointer();
|
|
|
|
|
if (executable_ptr) {
|
|
|
|
|
SymbolContextList sc_list;
|
|
|
|
|
ConstString main_name("main");
|
2021-08-05 09:27:19 -07:00
|
|
|
|
|
|
|
|
ModuleFunctionSearchOptions function_options;
|
|
|
|
|
function_options.include_symbols =
|
|
|
|
|
false; // Force it to be a debug symbol.
|
|
|
|
|
function_options.include_inlines = true;
|
2020-02-17 19:25:52 +01:00
|
|
|
executable_ptr->FindFunctions(main_name, CompilerDeclContext(),
|
2024-10-29 13:23:33 -07:00
|
|
|
lldb::eFunctionNameTypeFull,
|
2021-08-05 09:27:19 -07:00
|
|
|
function_options, sc_list);
|
2023-05-04 18:19:15 -07:00
|
|
|
for (const SymbolContext &sc : sc_list) {
|
2013-03-19 00:20:55 +00:00
|
|
|
if (sc.function) {
|
|
|
|
|
lldb_private::LineEntry line_entry;
|
2025-02-06 09:17:50 +01:00
|
|
|
if (sc.function->GetAddress().CalculateSymbolContextLineEntry(
|
|
|
|
|
line_entry)) {
|
2024-08-30 10:58:32 -07:00
|
|
|
SetDefaultFileAndLine(line_entry.file_sp, line_entry.line);
|
|
|
|
|
return SupportFileAndLine(line_entry.file_sp, m_last_line);
|
2011-10-07 22:16:04 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2011-10-07 22:16:04 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2011-10-07 22:16:04 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2024-08-30 10:58:32 -07:00
|
|
|
|
|
|
|
|
return std::nullopt;
|
2011-09-08 22:13:49 +00:00
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
|
2024-08-30 10:58:32 -07:00
|
|
|
void SourceManager::FindLinesMatchingRegex(SupportFileSP support_file_sp,
|
2012-03-15 21:01:31 +00:00
|
|
|
RegularExpression ®ex,
|
|
|
|
|
uint32_t start_line,
|
|
|
|
|
uint32_t end_line,
|
|
|
|
|
std::vector<uint32_t> &match_lines) {
|
2011-09-21 01:17:13 +00:00
|
|
|
match_lines.clear();
|
2024-08-30 10:58:32 -07:00
|
|
|
FileSP file_sp = GetFile(support_file_sp);
|
2011-09-21 01:17:13 +00:00
|
|
|
if (!file_sp)
|
|
|
|
|
return;
|
|
|
|
|
return file_sp->FindLinesMatchingRegex(regex, start_line, end_line,
|
|
|
|
|
match_lines);
|
|
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
|
2024-08-30 07:18:55 -07:00
|
|
|
SourceManager::File::File(SupportFileSP support_file_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
|
|
|
lldb::DebuggerSP debugger_sp)
|
2024-08-30 13:16:26 -07:00
|
|
|
: m_support_file_sp(std::make_shared<SupportFile>()), m_checksum(),
|
|
|
|
|
m_mod_time(), m_debugger_wp(debugger_sp), m_target_wp(TargetSP()) {
|
2024-08-30 07:18:55 -07:00
|
|
|
CommonInitializer(support_file_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
|
|
|
}
|
|
|
|
|
|
2024-08-30 07:18:55 -07:00
|
|
|
SourceManager::File::File(SupportFileSP support_file_sp, TargetSP target_sp)
|
2024-08-30 13:16:26 -07:00
|
|
|
: m_support_file_sp(std::make_shared<SupportFile>()), m_checksum(),
|
|
|
|
|
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) {
|
2024-08-30 07:18:55 -07:00
|
|
|
CommonInitializer(support_file_sp, 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
|
|
|
}
|
|
|
|
|
|
2024-08-30 07:18:55 -07:00
|
|
|
void SourceManager::File::CommonInitializer(SupportFileSP support_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
|
|
|
TargetSP target_sp) {
|
2023-06-26 10:45:23 -07:00
|
|
|
// Set the file and update the modification time.
|
2024-08-30 07:18:55 -07:00
|
|
|
SetSupportFile(support_file_sp);
|
2023-06-26 10:45:23 -07: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
|
|
|
// Always update the source map modification ID if we have a target.
|
|
|
|
|
if (target_sp)
|
|
|
|
|
m_source_map_mod_id = target_sp->GetSourcePathMap().GetModificationID();
|
|
|
|
|
|
2023-06-26 10:45:23 -07:00
|
|
|
// File doesn't exist.
|
2016-11-09 14:04:08 +00:00
|
|
|
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) {
|
2023-06-26 10:45:23 -07:00
|
|
|
// If this is just a file name, try finding it in the target.
|
2024-08-30 07:18:55 -07:00
|
|
|
{
|
|
|
|
|
FileSpec file_spec = support_file_sp->GetSpecOnly();
|
|
|
|
|
if (!file_spec.GetDirectory() && file_spec.GetFilename()) {
|
|
|
|
|
bool check_inlines = false;
|
|
|
|
|
SymbolContextList sc_list;
|
|
|
|
|
size_t num_matches =
|
|
|
|
|
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;
|
|
|
|
|
}
|
2011-12-12 21:59:28 +00:00
|
|
|
}
|
2011-09-13 00:29:56 +00:00
|
|
|
}
|
2024-08-30 07:18:55 -07:00
|
|
|
if (!got_multiple) {
|
|
|
|
|
SymbolContext sc;
|
|
|
|
|
sc_list.GetContextAtIndex(0, sc);
|
|
|
|
|
if (sc.comp_unit)
|
2024-09-03 10:33:30 -07:00
|
|
|
SetSupportFile(sc.comp_unit->GetPrimarySupportFile());
|
2024-08-30 07:18:55 -07:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2011-09-13 00:29:56 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2023-06-26 10:45:23 -07:00
|
|
|
|
|
|
|
|
// Try remapping the file if it doesn't exist.
|
2024-08-30 07:18:55 -07:00
|
|
|
{
|
|
|
|
|
FileSpec file_spec = support_file_sp->GetSpecOnly();
|
|
|
|
|
if (!FileSystem::Instance().Exists(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).
|
|
|
|
|
auto remapped = target_sp->GetSourcePathMap().FindFile(file_spec);
|
|
|
|
|
if (!remapped) {
|
|
|
|
|
FileSpec new_spec;
|
|
|
|
|
if (target_sp->GetImages().FindSourceFile(file_spec, new_spec))
|
|
|
|
|
remapped = new_spec;
|
|
|
|
|
}
|
|
|
|
|
if (remapped)
|
|
|
|
|
SetSupportFile(std::make_shared<SupportFile>(
|
|
|
|
|
*remapped, support_file_sp->GetChecksum()));
|
2021-06-29 14:59:12 -07:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2011-04-23 02:04:55 +00:00
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
2023-06-26 10:45:23 -07:00
|
|
|
// If the file exists, read in the data.
|
2024-08-30 13:16:26 -07:00
|
|
|
if (m_mod_time != llvm::sys::TimePoint<>()) {
|
2024-08-30 07:18:55 -07:00
|
|
|
m_data_sp = FileSystem::Instance().CreateDataBuffer(
|
|
|
|
|
m_support_file_sp->GetSpecOnly());
|
2024-08-30 13:16:26 -07:00
|
|
|
m_checksum = llvm::MD5::hash(m_data_sp->GetData());
|
|
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
2024-08-30 07:18:55 -07:00
|
|
|
void SourceManager::File::SetSupportFile(lldb::SupportFileSP support_file_sp) {
|
|
|
|
|
FileSpec file_spec = support_file_sp->GetSpecOnly();
|
2023-06-26 10:45:23 -07:00
|
|
|
resolve_tilde(file_spec);
|
2024-08-30 07:18:55 -07:00
|
|
|
m_support_file_sp =
|
|
|
|
|
std::make_shared<SupportFile>(file_spec, support_file_sp->GetChecksum());
|
|
|
|
|
m_mod_time = FileSystem::Instance().GetModificationTime(file_spec);
|
2023-06-26 10:45:23 -07:00
|
|
|
}
|
|
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
uint32_t SourceManager::File::GetLineOffset(uint32_t line) {
|
|
|
|
|
if (line == 0)
|
|
|
|
|
return UINT32_MAX;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
if (line == 1)
|
|
|
|
|
return 0;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
if (CalculateLineOffsets(line)) {
|
|
|
|
|
if (line < m_offsets.size())
|
|
|
|
|
return m_offsets[line - 1]; // yes we want "line - 1" in the index
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
return UINT32_MAX;
|
|
|
|
|
}
|
|
|
|
|
|
2014-01-27 23:43:24 +00:00
|
|
|
uint32_t SourceManager::File::GetNumLines() {
|
|
|
|
|
CalculateLineOffsets();
|
|
|
|
|
return m_offsets.size();
|
|
|
|
|
}
|
|
|
|
|
|
|
|
|
|
const char *SourceManager::File::PeekLineData(uint32_t line) {
|
|
|
|
|
if (!LineIsValid(line))
|
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
2019-05-23 11:14:47 +00:00
|
|
|
return nullptr;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2014-01-27 23:43:24 +00:00
|
|
|
size_t line_offset = GetLineOffset(line);
|
|
|
|
|
if (line_offset < m_data_sp->GetByteSize())
|
|
|
|
|
return (const char *)m_data_sp->GetBytes() + line_offset;
|
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
2019-05-23 11:14:47 +00:00
|
|
|
return nullptr;
|
2014-01-27 23:43:24 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
uint32_t SourceManager::File::GetLineLength(uint32_t line,
|
|
|
|
|
bool include_newline_chars) {
|
|
|
|
|
if (!LineIsValid(line))
|
|
|
|
|
return false;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2014-01-27 23:43:24 +00:00
|
|
|
size_t start_offset = GetLineOffset(line);
|
|
|
|
|
size_t end_offset = GetLineOffset(line + 1);
|
|
|
|
|
if (end_offset == UINT32_MAX)
|
|
|
|
|
end_offset = m_data_sp->GetByteSize();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2014-01-27 23:43:24 +00:00
|
|
|
if (end_offset > start_offset) {
|
|
|
|
|
uint32_t length = end_offset - start_offset;
|
2018-12-15 00:15:33 +00:00
|
|
|
if (!include_newline_chars) {
|
2014-01-27 23:43:24 +00:00
|
|
|
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;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2014-01-27 23:43:24 +00:00
|
|
|
return 0;
|
|
|
|
|
}
|
|
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
bool SourceManager::File::LineIsValid(uint32_t line) {
|
|
|
|
|
if (line == 0)
|
|
|
|
|
return false;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
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 {
|
2010-12-08 20:16:12 +00:00
|
|
|
// 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.
|
2024-08-30 07:18:55 -07:00
|
|
|
auto curr_mod_time = FileSystem::Instance().GetModificationTime(
|
|
|
|
|
m_support_file_sp->GetSpecOnly());
|
[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;
|
|
|
|
|
}
|
2016-09-06 20:57:50 +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
|
|
|
bool SourceManager::File::PathRemappingIsStale() const {
|
|
|
|
|
if (TargetSP target_sp = m_target_wp.lock())
|
|
|
|
|
return GetSourceMapModificationID() !=
|
|
|
|
|
target_sp->GetSourcePathMap().GetModificationID();
|
|
|
|
|
return false;
|
2015-07-29 18:37:25 +00:00
|
|
|
}
|
2010-12-08 20:16:12 +00:00
|
|
|
|
2018-08-30 00:09:21 +00:00
|
|
|
size_t SourceManager::File::DisplaySourceLines(uint32_t line,
|
2023-01-07 14:18:35 -08:00
|
|
|
std::optional<size_t> column,
|
2015-07-29 18:37:25 +00:00
|
|
|
uint32_t context_before,
|
2010-06-08 16:52:24 +00:00
|
|
|
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;
|
|
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
// Sanity check m_data_sp before proceeding.
|
|
|
|
|
if (!m_data_sp)
|
|
|
|
|
return 0;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2018-08-14 17:12:54 +00:00
|
|
|
size_t bytes_written = s->GetWrittenBytes();
|
|
|
|
|
|
2018-08-30 00:09:21 +00:00
|
|
|
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());
|
2018-08-02 00:30:15 +00:00
|
|
|
|
|
|
|
|
HighlighterManager mgr;
|
2024-08-30 07:18:55 -07:00
|
|
|
std::string path =
|
|
|
|
|
GetSupportFile()->GetSpecOnly().GetPath(/*denormalize*/ false);
|
2018-08-02 00:30:15 +00:00
|
|
|
// FIXME: Find a way to get the definitive language this file was written in
|
|
|
|
|
// and pass it to the highlighter.
|
2018-08-30 00:09:21 +00:00
|
|
|
const auto &h = mgr.getHighlighterFor(lldb::eLanguageTypeUnknown, path);
|
2018-08-02 00:30:15 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
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();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
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
|
|
|
|
2018-08-02 00:30:15 +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
|
|
|
|
2018-08-30 00:09:21 +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.
|
2018-08-02 00:30:15 +00:00
|
|
|
if (!is_newline_char(ref.back()))
|
2018-08-14 17:12:54 +00:00
|
|
|
s->EOL();
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
|
|
|
|
}
|
2018-08-14 17:12:54 +00:00
|
|
|
return s->GetWrittenBytes() - bytes_written;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
|
2011-09-21 01:17:13 +00:00
|
|
|
void SourceManager::File::FindLinesMatchingRegex(
|
|
|
|
|
RegularExpression ®ex, uint32_t start_line, uint32_t end_line,
|
|
|
|
|
std::vector<uint32_t> &match_lines) {
|
|
|
|
|
match_lines.clear();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-09-21 01:17:13 +00:00
|
|
|
if (!LineIsValid(start_line) ||
|
|
|
|
|
(end_line != UINT32_MAX && !LineIsValid(end_line)))
|
|
|
|
|
return;
|
|
|
|
|
if (start_line > end_line)
|
|
|
|
|
return;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2011-09-21 01:17:13 +00:00
|
|
|
for (uint32_t line_no = start_line; line_no < end_line; line_no++) {
|
|
|
|
|
std::string buffer;
|
|
|
|
|
if (!GetLine(line_no, buffer))
|
|
|
|
|
break;
|
2016-09-21 16:01:28 +00:00
|
|
|
if (regex.Execute(buffer)) {
|
2011-09-21 01:17:13 +00:00
|
|
|
match_lines.push_back(line_no);
|
|
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2011-09-21 01:17:13 +00:00
|
|
|
}
|
|
|
|
|
|
2011-09-13 00:29:56 +00:00
|
|
|
bool lldb_private::operator==(const SourceManager::File &lhs,
|
|
|
|
|
const SourceManager::File &rhs) {
|
2024-08-30 07:18:55 -07:00
|
|
|
if (!lhs.GetSupportFile()->Equal(*rhs.GetSupportFile(),
|
|
|
|
|
SupportFile::eEqualChecksumIfSet))
|
2010-06-08 16:52:24 +00:00
|
|
|
return false;
|
2016-11-09 14:04:08 +00:00
|
|
|
return lhs.m_mod_time == rhs.m_mod_time;
|
2011-09-13 00:29:56 +00:00
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
|
|
|
|
|
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;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
if (m_offsets.empty()) {
|
[lldb] NFC modernize codebase with modernize-use-nullptr
Summary:
NFC = [[ https://llvm.org/docs/Lexicon.html#nfc | Non functional change ]]
This commit is the result of modernizing the LLDB codebase by using
`nullptr` instread of `0` or `NULL`. See
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-nullptr.html
for more information.
This is the command I ran and I to fix and format the code base:
```
run-clang-tidy.py \
-header-filter='.*' \
-checks='-*,modernize-use-nullptr' \
-fix ~/dev/llvm-project/lldb/.* \
-format \
-style LLVM \
-p ~/llvm-builds/debug-ninja-gcc
```
NOTE: There were also changes to `llvm/utils/unittest` but I did not
include them because I felt that maybe this library shall be updated in
isolation somehow.
NOTE: I know this is a rather large commit but it is a nobrainer in most
parts.
Reviewers: martong, espindola, shafik, #lldb, JDevlieghere
Reviewed By: JDevlieghere
Subscribers: arsenm, jvesely, nhaehnle, hiraditya, JDevlieghere, teemperor, rnkovacs, emaste, kubamracek, nemanjai, ki.stfu, javed.absar, arichardson, kbarton, jrtc27, MaskRay, atanasyan, dexonsmith, arphaman, jfb, jsji, jdoerfert, lldb-commits, llvm-commits
Tags: #lldb, #llvm
Differential Revision: https://reviews.llvm.org/D61847
llvm-svn: 361484
2019-05-23 11:14:47 +00:00
|
|
|
if (m_data_sp.get() == nullptr)
|
2010-06-08 16:52:24 +00:00
|
|
|
return false;
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2022-04-01 15:59:18 -07:00
|
|
|
const char *start = (const char *)m_data_sp->GetBytes();
|
2010-06-08 16:52:24 +00:00
|
|
|
if (start) {
|
|
|
|
|
const char *end = start + m_data_sp->GetByteSize();
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
// Calculate all line offsets from scratch
|
2016-09-06 20:57:50 +00:00
|
|
|
|
2010-06-08 16:52:24 +00:00
|
|
|
// Push a 1 at index zero to indicate the file has been completely
|
|
|
|
|
// indexed.
|
|
|
|
|
m_offsets.push_back(UINT32_MAX);
|
2013-08-30 17:50:57 +00:00
|
|
|
const char *s;
|
2010-06-08 16:52:24 +00:00
|
|
|
for (s = start; s < end; ++s) {
|
2013-08-30 17:50:57 +00:00
|
|
|
char curr_ch = *s;
|
2010-06-08 16:52:24 +00:00
|
|
|
if (is_newline_char(curr_ch)) {
|
2013-02-07 03:38:34 +00:00
|
|
|
if (s + 1 < end) {
|
2013-08-30 17:50:57 +00:00
|
|
|
char next_ch = s[1];
|
2013-02-07 03:38:34 +00:00
|
|
|
if (is_newline_char(next_ch)) {
|
|
|
|
|
if (curr_ch != next_ch)
|
|
|
|
|
++s;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
m_offsets.push_back(s + 1 - start);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
if (!m_offsets.empty()) {
|
2016-10-05 17:07:34 +00:00
|
|
|
if (m_offsets.back() < size_t(end - start))
|
2015-08-26 23:55:14 +00:00
|
|
|
m_offsets.push_back(end - start);
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
2011-09-13 00:29:56 +00:00
|
|
|
return true;
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
|
|
|
|
} else {
|
|
|
|
|
// Some lines have been populated, start where we last left off
|
2015-08-26 23:55:14 +00:00
|
|
|
assert("Not implemented yet" && false);
|
2010-06-08 16:52:24 +00:00
|
|
|
}
|
2016-09-06 20:57:50 +00:00
|
|
|
|
|
|
|
|
} else {
|
2010-06-08 16:52:24 +00:00
|
|
|
// Calculate all line offsets up to "line"
|
2015-08-26 23:55:14 +00:00
|
|
|
assert("Not implemented yet" && false);
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2010-06-08 16:52:24 +00:00
|
|
|
return false;
|
|
|
|
|
}
|
2011-09-13 00:29:56 +00:00
|
|
|
|
2011-09-21 01:17:13 +00:00
|
|
|
bool SourceManager::File::GetLine(uint32_t line_no, std::string &buffer) {
|
|
|
|
|
if (!LineIsValid(line_no))
|
|
|
|
|
return false;
|
|
|
|
|
|
2013-01-25 18:06:21 +00:00
|
|
|
size_t start_offset = GetLineOffset(line_no);
|
|
|
|
|
size_t end_offset = GetLineOffset(line_no + 1);
|
2011-09-21 01:17:13 +00:00
|
|
|
if (end_offset == UINT32_MAX) {
|
|
|
|
|
end_offset = m_data_sp->GetByteSize();
|
|
|
|
|
}
|
2022-04-01 15:59:18 -07:00
|
|
|
buffer.assign((const char *)m_data_sp->GetBytes() + start_offset,
|
2011-09-21 01:17:13 +00:00
|
|
|
end_offset - start_offset);
|
|
|
|
|
|
2011-09-13 00:29:56 +00:00
|
|
|
return true;
|
|
|
|
|
}
|
|
|
|
|
|
2023-06-26 10:45:23 -07:00
|
|
|
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);
|
|
|
|
|
|
2023-06-26 10:45:23 -07:00
|
|
|
assert(file_sp && "invalid FileSP");
|
|
|
|
|
|
|
|
|
|
AddSourceFileImpl(file_spec, file_sp);
|
2024-08-30 07:18:55 -07:00
|
|
|
const FileSpec &resolved_file_spec = file_sp->GetSupportFile()->GetSpecOnly();
|
2023-06-26 10:45:23 -07:00
|
|
|
if (file_spec != resolved_file_spec)
|
2024-08-30 07:18:55 -07:00
|
|
|
AddSourceFileImpl(file_sp->GetSupportFile()->GetSpecOnly(), file_sp);
|
2023-06-26 10:45:23 -07: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
|
|
|
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++;
|
|
|
|
|
}
|
|
|
|
|
}
|
|
|
|
|
|
2023-06-26 10:45:23 -07:00
|
|
|
void SourceManager::SourceFileCache::AddSourceFileImpl(
|
|
|
|
|
const FileSpec &file_spec, FileSP file_sp) {
|
2011-09-13 00:29:56 +00:00
|
|
|
FileCache::iterator pos = m_file_cache.find(file_spec);
|
2023-06-26 10:45:23 -07:00
|
|
|
if (pos == m_file_cache.end()) {
|
2011-09-13 00:29:56 +00:00
|
|
|
m_file_cache[file_spec] = file_sp;
|
2023-06-26 10:45:23 -07:00
|
|
|
} else {
|
2011-09-13 00:29:56 +00:00
|
|
|
if (file_sp != pos->second)
|
|
|
|
|
m_file_cache[file_spec] = file_sp;
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2011-09-13 00:29:56 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
|
|
SourceManager::FileSP SourceManager::SourceFileCache::FindSourceFile(
|
2010-06-08 16:52:24 +00:00
|
|
|
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);
|
|
|
|
|
|
2011-09-13 00:29:56 +00:00
|
|
|
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 {};
|
2016-09-06 20:57:50 +00:00
|
|
|
}
|
2023-06-26 09:16:23 -07:00
|
|
|
|
|
|
|
|
void SourceManager::SourceFileCache::Dump(Stream &stream) const {
|
2024-08-30 13:16:26 -07:00
|
|
|
// clang-format off
|
|
|
|
|
stream << "Modification time MD5 Checksum (on-disk) MD5 Checksum (line table) Lines Path\n";
|
|
|
|
|
stream << "------------------- -------------------------------- -------------------------------- -------- --------------------------------\n";
|
|
|
|
|
// clang-format on
|
2023-06-26 09:16:23 -07:00
|
|
|
for (auto &entry : m_file_cache) {
|
|
|
|
|
if (!entry.second)
|
|
|
|
|
continue;
|
|
|
|
|
FileSP file = entry.second;
|
2024-08-30 13:16:26 -07:00
|
|
|
stream.Format("{0:%Y-%m-%d %H:%M:%S} {1,32} {2,32} {3,8:d} {4}\n",
|
|
|
|
|
file->GetTimestamp(), toString(file->GetChecksum()),
|
|
|
|
|
toString(file->GetSupportFile()->GetChecksum()),
|
2023-06-26 09:16:23 -07:00
|
|
|
file->GetNumLines(), entry.first.GetPath());
|
|
|
|
|
}
|
|
|
|
|
}
|