|
Revision tags: llvmorg-20.1.0, llvmorg-20.1.0-rc3, llvmorg-20.1.0-rc2, llvmorg-20.1.0-rc1, llvmorg-21-init, llvmorg-19.1.7, llvmorg-19.1.6, llvmorg-19.1.5, llvmorg-19.1.4, llvmorg-19.1.3, llvmorg-19.1.2, llvmorg-19.1.1, llvmorg-19.1.0, llvmorg-19.1.0-rc4, llvmorg-19.1.0-rc3, llvmorg-19.1.0-rc2, llvmorg-19.1.0-rc1, llvmorg-20-init, llvmorg-18.1.8, llvmorg-18.1.7, llvmorg-18.1.6, llvmorg-18.1.5, llvmorg-18.1.4, llvmorg-18.1.3, llvmorg-18.1.2, 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, llvmorg-17.0.6, llvmorg-17.0.5, llvmorg-17.0.4, 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, llvmorg-16.0.6, llvmorg-16.0.5, llvmorg-16.0.4, 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, llvmorg-15.0.6, llvmorg-15.0.5, llvmorg-15.0.4, llvmorg-15.0.3, 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 |
|
| #
5cff5142 |
| 16-Jul-2022 |
Kazu Hirata <[email protected]> |
Use value instead of getValue (NFC)
|
| #
96d1b4dd |
| 27-Jun-2022 |
Kazu Hirata <[email protected]> |
[lld] Don't use Optional::hasValue (NFC)
This patch replaces x.hasValue() with x where x is contextually convertible to bool.
|
| #
3b7c3a65 |
| 25-Jun-2022 |
Kazu Hirata <[email protected]> |
Revert "Don't use Optional::hasValue (NFC)"
This reverts commit aa8feeefd3ac6c78ee8f67bf033976fc7d68bc6d.
|
| #
aa8feeef |
| 25-Jun-2022 |
Kazu Hirata <[email protected]> |
Don't use Optional::hasValue (NFC)
|
|
Revision tags: llvmorg-14.0.6 |
|
| #
064a08cd |
| 21-Jun-2022 |
Kazu Hirata <[email protected]> |
Don't use Optional::hasValue (NFC)
|
|
Revision tags: llvmorg-14.0.5, llvmorg-14.0.4 |
|
| #
7d8ec4dc |
| 17-May-2022 |
David Spickett <[email protected]> |
[lldb] const a couple of getters on MemoryRegionInfo
GetDirtyPageList was being assigned to const & in most places anyway. If you wanted to change the list you'd make a new one and call SetDirtyPage
[lldb] const a couple of getters on MemoryRegionInfo
GetDirtyPageList was being assigned to const & in most places anyway. If you wanted to change the list you'd make a new one and call SetDirtyPageList.
GetPageSize is just an int so no issues being const.
Differential Revision: https://reviews.llvm.org/D125786
show more ...
|
|
Revision tags: llvmorg-14.0.3, llvmorg-14.0.2, llvmorg-14.0.1, llvmorg-14.0.0, llvmorg-14.0.0-rc4, llvmorg-14.0.0-rc3, llvmorg-14.0.0-rc2, llvmorg-14.0.0-rc1, llvmorg-15-init, llvmorg-13.0.1, llvmorg-13.0.1-rc3 |
|
| #
1755f5b1 |
| 19-Jan-2022 |
Jonas Devlieghere <[email protected]> |
[lldb] Decouple instrumentation from the reproducers
Remove the last remaining references to the reproducers from the instrumentation. This patch renames the relevant files and macros.
Differential
[lldb] Decouple instrumentation from the reproducers
Remove the last remaining references to the reproducers from the instrumentation. This patch renames the relevant files and macros.
Differential revision: https://reviews.llvm.org/D117712
show more ...
|
|
Revision tags: llvmorg-13.0.1-rc2 |
|
| #
d232abc3 |
| 10-Jan-2022 |
Jonas Devlieghere <[email protected]> |
[lldb] Remove LLDB_RECORD_RESULT macro
|
| #
d51402ac |
| 08-Jan-2022 |
Jonas Devlieghere <[email protected]> |
[lldb] Remove reproducer instrumentation
This patch removes most of the reproducer instrumentation. It keeps around the LLDB_RECORD_* macros for logging. See [1] for more details.
[1] https://lists
[lldb] Remove reproducer instrumentation
This patch removes most of the reproducer instrumentation. It keeps around the LLDB_RECORD_* macros for logging. See [1] for more details.
[1] https://lists.llvm.org/pipermail/lldb-dev/2021-September/017045.html
Differential revision: https://reviews.llvm.org/D116847
show more ...
|
| #
a3436f73 |
| 03-Jan-2022 |
Kazu Hirata <[email protected]> |
[API] Remove redundant member initialization (NFC)
Identified with readability-redundant-member-init.
|
|
Revision tags: llvmorg-13.0.1-rc1 |
|
| #
a758c9f7 |
| 08-Oct-2021 |
Med Ismail Bennani <[email protected]> |
[lldb/Plugins] Add memory region support in ScriptedProcess
This patch adds support for memory regions in Scripted Processes. This is necessary to read the stack memory region in order to reconstruc
[lldb/Plugins] Add memory region support in ScriptedProcess
This patch adds support for memory regions in Scripted Processes. This is necessary to read the stack memory region in order to reconstruct each stackframe of the program.
In order to do so, this patch makes some changes to the SBAPI, namely: - Add a new constructor for `SBMemoryRegionInfo` that takes arguments such as the memory region name, address range, permissions ... This is used when reading memory at some address to compute the offset in the binary blob provided by the user. - Add a `GetMemoryRegionContainingAddress` method to `SBMemoryRegionInfoList` to simplify the access to a specific memory region.
With these changes, lldb is now able to unwind the stack and reconstruct each frame. On top of that, reloading the target module at offset 0 allows lldb to symbolicate the `ScriptedProcess` using debug info, similarly to an ordinary Process.
To test this, I wrote a simple program with multiple function calls, ran it in lldb, stopped at a leaf function and read the registers values and copied the stack memory into a binary file. These are then used in the python script.
Differential Revision: https://reviews.llvm.org/D108953
Signed-off-by: Med Ismail Bennani <[email protected]>
show more ...
|
|
Revision tags: llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2 |
|
| #
aa575ed9 |
| 16-Aug-2021 |
Jason Molenda <[email protected]> |
Ah, fix formatting, I didn't notice lldb-instr's code additions were unusually formatted.
|
| #
65bc8ba1 |
| 16-Aug-2021 |
Jason Molenda <[email protected]> |
Correctly update reproducer hooks for SB API I added
In 9ea6dd5cfac0b233fbb148c1e2d0f81f816737c8 / https://reviews.llvm.org/D88387 where I added skinny corefile creation, I added new SB API and trie
Correctly update reproducer hooks for SB API I added
In 9ea6dd5cfac0b233fbb148c1e2d0f81f816737c8 / https://reviews.llvm.org/D88387 where I added skinny corefile creation, I added new SB API and tried to manually update the hooks for the reproducers. I missed a spot, and I should have used lldb-instr to update the instrumentation automatically.
show more ...
|
|
Revision tags: llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3 |
|
| #
9ea6dd5c |
| 20-Jun-2021 |
Jason Molenda <[email protected]> |
Add a corefile style option to process save-core; skinny corefiles
Add a new feature to process save-core on Darwin systems -- for lldb to create a user process corefile with only the dirty (modifie
Add a corefile style option to process save-core; skinny corefiles
Add a new feature to process save-core on Darwin systems -- for lldb to create a user process corefile with only the dirty (modified memory) pages included. All of the binaries that were used in the corefile are assumed to still exist on the system for the duration of the use of the corefile. A new --style option to process save-core is added, so a full corefile can be requested if portability across systems, or across time, is needed for this corefile.
debugserver can now identify the dirty pages in a memory region when queried with qMemoryRegionInfo, and the size of vm pages is given in qHostInfo.
Create a new "all image infos" LC_NOTE for Mach-O which allows us to describe all of the binaries that were loaded in the process -- load address, UUID, file path, segment load addresses, and optionally whether code from the binary was executing on any thread. The old "read dyld_all_image_infos and then the in-memory Mach-O load commands to get segment load addresses" no longer works when we only have dirty memory.
rdar://69670807 Differential Revision: https://reviews.llvm.org/D88387
show more ...
|
|
Revision tags: llvmorg-12.0.1-rc2, llvmorg-12.0.1-rc1, llvmorg-12.0.0, llvmorg-12.0.0-rc5, llvmorg-12.0.0-rc4, llvmorg-12.0.0-rc3, llvmorg-12.0.0-rc2, llvmorg-11.1.0, llvmorg-11.1.0-rc3, llvmorg-12.0.0-rc1, llvmorg-13-init, llvmorg-11.1.0-rc2, llvmorg-11.1.0-rc1, llvmorg-11.0.1, llvmorg-11.0.1-rc2, llvmorg-11.0.1-rc1, llvmorg-11.0.0, llvmorg-11.0.0-rc6, llvmorg-11.0.0-rc5, llvmorg-11.0.0-rc4, llvmorg-11.0.0-rc3, llvmorg-11.0.0-rc2, llvmorg-11.0.0-rc1, llvmorg-12-init, llvmorg-10.0.1, llvmorg-10.0.1-rc4, llvmorg-10.0.1-rc3, llvmorg-10.0.1-rc2, llvmorg-10.0.1-rc1, llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3 |
|
| #
866b7a65 |
| 18-Feb-2020 |
Jonas Devlieghere <[email protected]> |
[lldb] Replace empty ctor en dtor bodies with =default (NFC)
Use = default instead of empty constructor and destructor bodies in the API layer.
|
|
Revision tags: llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1 |
|
| #
80814287 |
| 24-Jan-2020 |
Raphael Isemann <[email protected]> |
[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 ----------------------------------------
[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
show more ...
|
|
Revision tags: llvmorg-11-init, llvmorg-9.0.1, llvmorg-9.0.1-rc3, llvmorg-9.0.1-rc2, llvmorg-9.0.1-rc1, llvmorg-9.0.0, llvmorg-9.0.0-rc6, llvmorg-9.0.0-rc5, llvmorg-9.0.0-rc4, llvmorg-9.0.0-rc3, llvmorg-9.0.0-rc2, llvmorg-9.0.0-rc1, llvmorg-10-init, llvmorg-8.0.1, llvmorg-8.0.1-rc4, llvmorg-8.0.1-rc3, llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1 |
|
| #
306809f2 |
| 03-Apr-2019 |
Jonas Devlieghere <[email protected]> |
[Reproducers] Capture return values of functions returning by ptr/ref
For some reason I had convinced myself that functions returning by pointer or reference do not require recording their result. H
[Reproducers] Capture return values of functions returning by ptr/ref
For some reason I had convinced myself that functions returning by pointer or reference do not require recording their result. However, after further considering I don't see how that could work, at least not with the current implementation. Interestingly enough, the reproducer instrumentation already (mostly) accounts for this, though the lldb-instr tool did not.
This patch adds the missing macros and updates the lldb-instr tool.
Differential revision: https://reviews.llvm.org/D60178
llvm-svn: 357639
show more ...
|
| #
ae211ece |
| 19-Mar-2019 |
Michal Gorny <[email protected]> |
[lldb] [Reproducer] Move SBRegistry registration into declaring files
Move SBRegistry method registrations from SBReproducer.cpp into files declaring the individual APIs, in order to reduce the memo
[lldb] [Reproducer] Move SBRegistry registration into declaring files
Move SBRegistry method registrations from SBReproducer.cpp into files declaring the individual APIs, in order to reduce the memory consumption during build and improve maintainability. The current humongous SBRegistry constructor exhausts all memory on a NetBSD system with 4G RAM + 4G swap, therefore making it impossible to build LLDB.
Differential Revision: https://reviews.llvm.org/D59427
llvm-svn: 356481
show more ...
|
|
Revision tags: llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4 |
|
| #
baf5664f |
| 06-Mar-2019 |
Jonas Devlieghere <[email protected]> |
[Reproducers] Add SBReproducer macros
This patch adds the SBReproducer macros needed to capture and reply the corresponding calls. This patch was generated by running the lldb-instr tool on the API
[Reproducers] Add SBReproducer macros
This patch adds the SBReproducer macros needed to capture and reply the corresponding calls. This patch was generated by running the lldb-instr tool on the API source files.
Differential revision: https://reviews.llvm.org/D57475
llvm-svn: 355459
show more ...
|
| #
bd4bf82a |
| 06-Mar-2019 |
Jonas Devlieghere <[email protected]> |
[SBAPI] Don't check IsValid in constructor
When running the test suite with the instrumentation macros, I noticed two lldb-mi tests regressed. The issue was the copy constructor of SBLineEntry. With
[SBAPI] Don't check IsValid in constructor
When running the test suite with the instrumentation macros, I noticed two lldb-mi tests regressed. The issue was the copy constructor of SBLineEntry. Without the macros the returned value would be elided, but with the macros the copy constructor was called. The latter using ::IsValid to determine whether the underlying opaque pointer should be set. This is likely a remnant of when ::IsValid would only check the validity of the smart pointer. In SBLineEntry however, it actually forwards to LineEntry::IsValid().
So what happened here was that because of the macros the copy constructor was called. The opaque pointer was valid but the LineEntry didn't consider itself valid. So the copied-to object ended up default initialized.
This patch replaces all checks for IsValid in copy (assignment) constructors with checks for the opaque pointer itself.
Differential revision: https://reviews.llvm.org/D58946
llvm-svn: 355458
show more ...
|
|
Revision tags: llvmorg-8.0.0-rc3 |
|
| #
d5b44036 |
| 13-Feb-2019 |
Jonas Devlieghere <[email protected]> |
Replace 'ap' with 'up' suffix in variable names. (NFC)
The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique
Replace 'ap' with 'up' suffix in variable names. (NFC)
The `ap` suffix is a remnant of lldb's former use of auto pointers, before they got deprecated. Although all their uses were replaced by unique pointers, some variables still carried the suffix.
In r353795 I removed another auto_ptr remnant, namely redundant calls to ::get for unique_pointers. Jim justly noted that this is a good opportunity to clean up the variable names as well.
I went over all the changes to ensure my find-and-replace didn't have any undesired side-effects. I hope I didn't miss any, but if you end up at this commit doing a git blame on a weirdly named variable, please know that the change was unintentional.
llvm-svn: 353912
show more ...
|
|
Revision tags: llvmorg-7.1.0, llvmorg-7.1.0-rc1, llvmorg-8.0.0-rc2, llvmorg-8.0.0-rc1 |
|
| #
2946cd70 |
| 19-Jan-2019 |
Chandler Carruth <[email protected]> |
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license.
We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach.
Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository.
llvm-svn: 351636
show more ...
|
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3, llvmorg-7.0.1-rc2, llvmorg-7.0.1-rc1, llvmorg-7.0.0, llvmorg-7.0.0-rc3, llvmorg-7.0.0-rc2, llvmorg-7.0.0-rc1, llvmorg-6.0.1, llvmorg-6.0.1-rc3, llvmorg-6.0.1-rc2, llvmorg-6.0.1-rc1, llvmorg-5.0.2, llvmorg-5.0.2-rc2, llvmorg-5.0.2-rc1, llvmorg-6.0.0, llvmorg-6.0.0-rc3, llvmorg-6.0.0-rc2, llvmorg-6.0.0-rc1, llvmorg-5.0.1, llvmorg-5.0.1-rc3, llvmorg-5.0.1-rc2, llvmorg-5.0.1-rc1, llvmorg-5.0.0, llvmorg-5.0.0-rc5, llvmorg-5.0.0-rc4, llvmorg-5.0.0-rc3, llvmorg-5.0.0-rc2, llvmorg-5.0.0-rc1, llvmorg-4.0.1, llvmorg-4.0.1-rc3, llvmorg-4.0.1-rc2, llvmorg-4.0.1-rc1, llvmorg-4.0.0, llvmorg-4.0.0-rc4, llvmorg-4.0.0-rc3, llvmorg-4.0.0-rc2 |
|
| #
bf9a7730 |
| 02-Feb-2017 |
Zachary Turner <[email protected]> |
Move classes from Core -> Utility.
This moves the following classes from Core -> Utility.
ConstString Error RegularExpression Stream StreamString
The goal here is to get lldbUtility into a state w
Move classes from Core -> Utility.
This moves the following classes from Core -> Utility.
ConstString Error RegularExpression Stream StreamString
The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem.
Differential Revision: https://reviews.llvm.org/D29427
llvm-svn: 293941
show more ...
|
|
Revision tags: llvmorg-4.0.0-rc1, llvmorg-3.9.1, llvmorg-3.9.1-rc3, llvmorg-3.9.1-rc2, llvmorg-3.9.1-rc1 |
|
| #
b9c1b51e |
| 06-Sep-2016 |
Kate Stone <[email protected]> |
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications:
Firstly, merging t
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications:
Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository):
find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ;
The version of clang-format used was 3.9.0, and autopep8 was 1.2.4.
Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
show more ...
|
|
Revision tags: llvmorg-3.9.0, llvmorg-3.9.0-rc3, llvmorg-3.9.0-rc2, llvmorg-3.9.0-rc1 |
|
| #
d7d69f80 |
| 22-Jul-2016 |
Tamas Berghammer <[email protected]> |
Support loading files even when incorrect file name specified by the linker
"Incorrect" file name seen on Android whene the main executable is called "app_process32" (or 64) but the linker specifies
Support loading files even when incorrect file name specified by the linker
"Incorrect" file name seen on Android whene the main executable is called "app_process32" (or 64) but the linker specifies the package name (e.g. com.android.calculator2). Additionally it can be present in case of some linker bugs.
This CL adds logic to try to fetch the correct file name from the proc file system based on the base address sepcified by the linker in case we are failed to load the module by name.
Differential revision: http://reviews.llvm.org/D22219
llvm-svn: 276411
show more ...
|