Revision tags: llvmorg-21-init |
|
#
c4fb7180 |
| 15-Jan-2025 |
Greg Clayton <gclayton@fb.com> |
[lldb][NFC] Make the target's SectionLoadList private. (#113278)
Lots of code around LLDB was directly accessing the target's section
load list. This NFC patch makes the section load list private s
[lldb][NFC] Make the target's SectionLoadList private. (#113278)
Lots of code around LLDB was directly accessing the target's section
load list. This NFC patch makes the section load list private so the
Target class can access it, but everyone else now uses accessor
functions. This allows us to control the resolving of addresses and will
allow for functionality in LLDB which can lazily resolve addresses in
JIT plug-ins with a future patch.
show more ...
|
Revision tags: llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4 |
|
#
39b2979a |
| 13-Nov-2024 |
Pavel Labath <pavel@labath.sk> |
[lldb] Fix source display for artificial locations (#115876)
When retrieving the location of the function declaration, we were
dropping the file component on the floor, which resulted in an amusing
[lldb] Fix source display for artificial locations (#115876)
When retrieving the location of the function declaration, we were
dropping the file component on the floor, which resulted in an amusingly
confusing situation were we displayed the file containing the
implementation of the function, but used the line number of the
declaration. This patch fixes that.
It required a small refactor Function::GetStartLineSourceLineInfo to
return a SupportFile (instead of just the file spec), which in turn
necessitated changes in a couple of other places as well.
show more ...
|
Revision tags: llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0 |
|
#
98bde7fd |
| 03-Sep-2024 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Avoid FileSpec indirection where we can use SupportFiles directly
Now that more parts of LLDB know about SupportFiles, avoid going through FileSpec (and losing the Checksum in the process). I
[lldb] Avoid FileSpec indirection where we can use SupportFiles directly
Now that more parts of LLDB know about SupportFiles, avoid going through FileSpec (and losing the Checksum in the process). Instead, use the SupportFile directly.
show more ...
|
Revision tags: llvmorg-19.1.0-rc4 |
|
#
130eddf7 |
| 30-Aug-2024 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Deal with SupportFiles in SourceManager (NFC) (#106740)
To support detecting MD5 checksum mismatches, deal with SupportFiles
rather than a plain FileSpecs in the SourceManager.
|
#
ab40ae8f |
| 30-Aug-2024 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Store SupportFiles in SourceManager::File (NFC) (#106639)
To support detecting MD5 checksum mismatches, store a SupportFile rather
than a plain FileSpec in SourceManager::File.
|
#
0642cd76 |
| 27-Aug-2024 |
Adrian Prantl <aprantl@apple.com> |
[lldb] Turn lldb_private::Status into a value type. (#106163)
This patch removes all of the Set.* methods from Status.
This cleanup is part of a series of patches that make it harder use the
ant
[lldb] Turn lldb_private::Status into a value type. (#106163)
This patch removes all of the Set.* methods from Status.
This cleanup is part of a series of patches that make it harder use the
anti-pattern of keeping a long-lives Status object around and updating
it while dropping any errors it contains on the floor.
This patch is largely NFC, the more interesting next steps this enables
is to:
1. remove Status.Clear()
2. assert that Status::operator=() never overwrites an error
3. remove Status::operator=()
Note that step (2) will bring 90% of the benefits for users, and step
(3) will dramatically clean up the error handling code in various
places. In the end my goal is to convert all APIs that are of the form
` ResultTy DoFoo(Status& error)
`
to
` llvm::Expected<ResultTy> DoFoo()
`
How to read this patch?
The interesting changes are in Status.h and Status.cpp, all other
changes are mostly
` perl -pi -e 's/\.SetErrorString/ = Status::FromErrorString/g' $(git
grep -l SetErrorString lldb/source)
`
plus the occasional manual cleanup.
show more ...
|
Revision tags: llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2 |
|
#
c6ce324f |
| 02-Aug-2024 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Eliminate more Targer* in favor of Target& in CommandObjects (NFC)
The majority of the replaced Target pointers were already used unconditionally and the few that were shouldn't even be NULL.
|
Revision tags: llvmorg-19.1.0-rc1, llvmorg-20-init |
|
#
dd5df27d |
| 01-Jul-2024 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Make semantics of SupportFile equivalence explicit (#97126)
This is an improved attempt to improve the semantics of SupportFile
equivalence, taking into account the feedback from #95606.
[lldb] Make semantics of SupportFile equivalence explicit (#97126)
This is an improved attempt to improve the semantics of SupportFile
equivalence, taking into account the feedback from #95606.
Pavel's comment about the lack of a concise name because the concept
isn't trivial made me realize that I don't want to abstract this concept
away behind a helper function. Instead, I opted for a rather verbose
enum that forces the caller to consider exactly what kind of comparison
is appropriate for every call.
show more ...
|
Revision tags: llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3 |
|
#
556fe5f2 |
| 21-Mar-2024 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Reland: Store SupportFile in FileEntry (NFC) (#85892)
This is another step towards supporting DWARF5 checksums and inline
source code in LLDB. This is a reland of #85468 but without the
fun
[lldb] Reland: Store SupportFile in FileEntry (NFC) (#85892)
This is another step towards supporting DWARF5 checksums and inline
source code in LLDB. This is a reland of #85468 but without the
functional change of storing the support file from the line table (yet).
show more ...
|
#
a289f66e |
| 20-Mar-2024 |
Jonas Devlieghere <jonas@devlieghere.com> |
Revert "[lldb] Store SupportFile in FileEntry (NFC)" (#85885)
Reverts llvm/llvm-project#85468 because @slackito reports this broke
stepping in one of their tests [1] and this patch was meant to be
Revert "[lldb] Store SupportFile in FileEntry (NFC)" (#85885)
Reverts llvm/llvm-project#85468 because @slackito reports this broke
stepping in one of their tests [1] and this patch was meant to be NFC.
[1]
https://github.com/llvm/llvm-project/commit/d5a277d309e92b1d3e493da6036cffdf815105b1#commitcomment-139991120
show more ...
|
Revision tags: llvmorg-18.1.2 |
|
#
d5a277d3 |
| 15-Mar-2024 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Store SupportFile in FileEntry (NFC) (#85468)
This is another step towards supporting DWARF5 checksums and inline
source code in LLDB.
|
Revision tags: llvmorg-18.1.1, llvmorg-18.1.0, llvmorg-18.1.0-rc4, llvmorg-18.1.0-rc3, llvmorg-18.1.0-rc2, llvmorg-18.1.0-rc1, llvmorg-19-init |
|
#
933c25e5 |
| 17-Jan-2024 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Store SupportFile in LineEntry (NFC) (#77999)
Store a SupportFile, rather than a FileSpec, in LineEntry. This commit
works towards having the SourceManageroperate on SupportFiles so that it
[lldb] Store SupportFile in LineEntry (NFC) (#77999)
Store a SupportFile, rather than a FileSpec, in LineEntry. This commit
works towards having the SourceManageroperate on SupportFiles so that it
can (1) validate the Checksum and (2) materialize the content of inline
source information.
show more ...
|
#
917b404e |
| 04-Jan-2024 |
Adrian Prantl <adrian-prantl@users.noreply.github.com> |
Add support for inline DWARF source files. (#75880)
LLVM supports DWARF 5 linetable extension to store source files inline
in DWARF. This is particularly useful for compiler-generated source
code.
Add support for inline DWARF source files. (#75880)
LLVM supports DWARF 5 linetable extension to store source files inline
in DWARF. This is particularly useful for compiler-generated source
code. This implementation tries to materialize them as temporary files
lazily, so SBAPI clients don't need to be aware of them.
rdar://110926168
show more ...
|
Revision tags: llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4 |
|
#
92d8a28c |
| 30-Oct-2023 |
Pete Lawrence <plawrence@apple.com> |
[lldb] Part 2 of 2 - Refactor `CommandObject::DoExecute(...)` return `void` (not `bool`) (#69991)
[lldb] Part 2 of 2 - Refactor `CommandObject::DoExecute(...)` to return
`void` instead of ~~`bool`~
[lldb] Part 2 of 2 - Refactor `CommandObject::DoExecute(...)` return `void` (not `bool`) (#69991)
[lldb] Part 2 of 2 - Refactor `CommandObject::DoExecute(...)` to return
`void` instead of ~~`bool`~~
Justifications:
- The code doesn't ultimately apply the `true`/`false` return values.
- The methods already pass around a `CommandReturnObject`, typically
with a `result` parameter.
- Each command return object already contains:
- A more precise status
- The error code(s) that apply to that status
Part 1 refactors the `CommandObject::Execute(...)` method.
- See
[https://github.com/llvm/llvm-project/pull/69989](https://github.com/llvm/llvm-project/pull/69989)
rdar://117378957
show more ...
|
Revision tags: llvmorg-17.0.3, llvmorg-17.0.2, llvmorg-17.0.1, llvmorg-17.0.0, llvmorg-17.0.0-rc4, llvmorg-17.0.0-rc3, llvmorg-17.0.0-rc2, llvmorg-17.0.0-rc1, llvmorg-18-init |
|
#
51944e78 |
| 03-Jul-2023 |
Jonas Devlieghere <jonas@devlieghere.com> |
[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
[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
show more ...
|
#
d49caf4a |
| 26-Jun-2023 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Add `source cache dump` and `source cache clear` subcommand
Add two new source subcommands: source cache dump and source cache clear. As the name implies the first one dumps the source cache
[lldb] Add `source cache dump` and `source cache clear` subcommand
Add two new source subcommands: source cache dump and source cache clear. As the name implies the first one dumps the source cache while the later clears the cache.
This patch was motivated by a handful of (internal) bug reports related to sources not being available. Right now those issues can be hard to diagnose. The new commands give users, as well as us as developers, more insight into and control over the source cache.
Differential revision: https://reviews.llvm.org/D153685
show more ...
|
Revision tags: llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4 |
|
#
e9eaf7b4 |
| 05-May-2023 |
Alex Langford <alangford@apple.com> |
Re-land "[lldb] Expose a const iterator for SymbolContextList"
Re-lands 04aa943be8ed5c03092e2a90112ac638360ec253 with modifications to fix tests. I originally reverted this because it caused a test
Re-land "[lldb] Expose a const iterator for SymbolContextList"
Re-lands 04aa943be8ed5c03092e2a90112ac638360ec253 with modifications to fix tests. I originally reverted this because it caused a test to fail on Linux. The problem was that I inverted a condition on accident.
show more ...
|
#
3d6073a9 |
| 04-May-2023 |
Alex Langford <alangford@apple.com> |
Revert "[lldb] Expose a const iterator for SymbolContextList"
This reverts commit 04aa943be8ed5c03092e2a90112ac638360ec253.
This broke the debian buildbot and I'm not sure why. Reverting so I can i
Revert "[lldb] Expose a const iterator for SymbolContextList"
This reverts commit 04aa943be8ed5c03092e2a90112ac638360ec253.
This broke the debian buildbot and I'm not sure why. Reverting so I can investigate.
show more ...
|
#
04aa943b |
| 04-May-2023 |
Alex Langford <alangford@apple.com> |
[lldb] Expose a const iterator for SymbolContextList
There are many situations where we'll iterate over a SymbolContextList with the pattern: ``` SymbolContextList sc_list; // Fill in sc_list here f
[lldb] Expose a const iterator for SymbolContextList
There are many situations where we'll iterate over a SymbolContextList with the pattern: ``` SymbolContextList sc_list; // Fill in sc_list here for (auto i = 0; i < sc_list.GetSize(); i++) { SymbolContext sc; sc_list.GetSymbolAtContext(i, sc);
// Do work with sc } ``` Adding an iterator to iterate over the instances directly means we don't have to do bounds checking or create a copy of every element of the SymbolContextList.
Differential Revision: https://reviews.llvm.org/D149900
show more ...
|
Revision tags: llvmorg-16.0.3, llvmorg-16.0.2, llvmorg-16.0.1, llvmorg-16.0.0, llvmorg-16.0.0-rc4, llvmorg-16.0.0-rc3, llvmorg-16.0.0-rc2, llvmorg-16.0.0-rc1, llvmorg-17-init, llvmorg-15.0.7 |
|
#
984b800a |
| 09-Jan-2023 |
serge-sans-paille <sguelton@mozilla.com> |
Move from llvm::makeArrayRef to ArrayRef deduction guides - last part
This is a follow-up to https://reviews.llvm.org/D140896, split into several parts as it touches a lot of files.
Differential Re
Move from llvm::makeArrayRef to ArrayRef deduction guides - last part
This is a follow-up to https://reviews.llvm.org/D140896, split into several parts as it touches a lot of files.
Differential Revision: https://reviews.llvm.org/D141298
show more ...
|
#
2fe83274 |
| 07-Jan-2023 |
Kazu Hirata <kazu@google.com> |
[lldb] Use std::optional instead of llvm::Optional (NFC)
This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to clean up the "using" declarations, #include "llvm/
[lldb] Use std::optional instead of llvm::Optional (NFC)
This patch replaces (llvm::|)Optional< with std::optional<. I'll post a separate patch to clean up the "using" declarations, #include "llvm/ADT/Optional.h", etc.
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
show more ...
|
#
f190ce62 |
| 07-Jan-2023 |
Kazu Hirata <kazu@google.com> |
[lldb] Add #include <optional> (NFC)
This patch adds #include <optional> to those files containing llvm::Optional<...> or Optional<...>.
I'll post a separate patch to actually replace llvm::Optiona
[lldb] Add #include <optional> (NFC)
This patch adds #include <optional> to those files containing llvm::Optional<...> or Optional<...>.
I'll post a separate patch to actually replace llvm::Optional with std::optional.
This is part of an effort to migrate from llvm::Optional to std::optional:
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
show more ...
|
Revision tags: llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, working, llvmorg-15.0.2, llvmorg-15.0.1, llvmorg-15.0.0, llvmorg-15.0.0-rc3, llvmorg-15.0.0-rc2, llvmorg-15.0.0-rc1, llvmorg-16-init |
|
#
7ced9fff |
| 14-Jul-2022 |
Jonas Devlieghere <jonas@devlieghere.com> |
[lldb] Refactor command option enum values (NFC)
Refactor the command option enum values and the command argument table to connect the two. This has two benefits:
- We guarantee that two options t
[lldb] Refactor command option enum values (NFC)
Refactor the command option enum values and the command argument table to connect the two. This has two benefits:
- We guarantee that two options that use the same argument type have the same accepted values. - We can print the enum values and their description in the help output. (D129707)
Differential revision: https://reviews.llvm.org/D129703
show more ...
|
#
c1b07d61 |
| 23-Jun-2022 |
Jim Ingham <jingham@apple.com> |
Have CommandObjectParsed check for "commands that take no arguments".
This is currently being done in an ad hoc way, and so for some commands it isn't being checked. We have the info to make this c
Have CommandObjectParsed check for "commands that take no arguments".
This is currently being done in an ad hoc way, and so for some commands it isn't being checked. We have the info to make this check, since commands are supposed to add their arguments to the m_arguments field of the CommandObject. This change uses that info to check whether the command received arguments in error.
A handful of commands weren't defining their argument types, I also had to fix them. And a bunch of commands were checking for arguments by hand, so I removed those checks in favor of the CommandObject one. That also meant I had to change some tests that were checking for the ad hoc error outputs.
Differential Revision: https://reviews.llvm.org/D128453
show more ...
|
Revision tags: llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1 |
|
#
24f9a2f5 |
| 31-Mar-2022 |
Shafik Yaghmour <syaghmour@apple.com> |
[LLDB] Applying clang-tidy modernize-use-equals-default over LLDB
Applied modernize-use-equals-default clang-tidy check over LLDB.
This check is already present in the lldb/.clang-tidy config.
Dif
[LLDB] Applying clang-tidy modernize-use-equals-default over LLDB
Applied modernize-use-equals-default clang-tidy check over LLDB.
This check is already present in the lldb/.clang-tidy config.
Differential Revision: https://reviews.llvm.org/D121844
show more ...
|