|
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, llvmorg-14.0.6, llvmorg-14.0.5, llvmorg-14.0.4, 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, llvmorg-13.0.1-rc2, llvmorg-13.0.1-rc1, llvmorg-13.0.0, llvmorg-13.0.0-rc4, llvmorg-13.0.0-rc3, llvmorg-13.0.0-rc2, llvmorg-13.0.0-rc1, llvmorg-14-init, llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, 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 |
|
| #
b40ee7ff |
| 18-Mar-2020 |
Fred Riss <[email protected]> |
[lldb/MemoryHistoryAsan] Fix address resolution for recorded backtraces
Summary: The memory history plugin for Asan creates a HistoryThread with the recorded PC values provided by the Asan runtime.
[lldb/MemoryHistoryAsan] Fix address resolution for recorded backtraces
Summary: The memory history plugin for Asan creates a HistoryThread with the recorded PC values provided by the Asan runtime. In other cases, thoses PCs are gathered by LLDB directly.
The PCs returned by the Asan runtime are the PCs of the calls in the backtrace, not the return addresses you would normally get when unwinding the stack (look for a call to GetPreviousIntructionPc in AsanGetStack).
When the above addresses are passed to the unwinder, it will subtract 1 from each address of the non zero frames because it treats them as return addresses. This can lead to the final report referencing the wrong line.
This patch fixes this issue by threading a flag through HistoryThread and HistoryUnwinder that tells them to treat every frame like the first one. The Asan MemoryHistory plugin can then use this flag.
This fixes running TestMemoryHistory on arm64 devices, although it's hard to guarantee that the test will continue to exhibit the boundary condition that triggers this bug.
Reviewers: jasonmolenda, kubamracek
Subscribers: kristof.beyls, danielkiss, lldb-commits
Tags: #lldb
Differential Revision: https://reviews.llvm.org/D76341
show more ...
|
|
Revision tags: llvmorg-10.0.0-rc4, llvmorg-10.0.0-rc3 |
|
| #
cdc514e4 |
| 17-Feb-2020 |
Jonas Devlieghere <[email protected]> |
[lldb] Update header guards to be consistent and compliant with LLVM (NFC)
LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pa
[lldb] Update header guards to be consistent and compliant with LLVM (NFC)
LLDB has a few different styles of header guards and they're not very consistent because things get moved around or copy/pasted. This patch unifies the header guards across LLDB and converts everything to match LLVM's style.
Differential revision: https://reviews.llvm.org/D74743
show more ...
|
|
Revision tags: llvmorg-10.0.0-rc2, llvmorg-10.0.0-rc1, 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 |
|
| #
86df61cc |
| 19-Jun-2019 |
Alex Langford <[email protected]> |
[Process] Remove unused field from HistoryThread
Summary: These fields are unused and have been since their inception, from what I can tell.
Reviewers: compnerd, JDevlieghere, davide, labath
Subsc
[Process] Remove unused field from HistoryThread
Summary: These fields are unused and have been since their inception, from what I can tell.
Reviewers: compnerd, JDevlieghere, davide, labath
Subscribers: kubamracek, lldb-commits
Differential Revision: https://reviews.llvm.org/D63357
llvm-svn: 363881
show more ...
|
|
Revision tags: llvmorg-8.0.1-rc2, llvmorg-8.0.1-rc1 |
|
| #
8b3af63b |
| 10-Apr-2019 |
Jonas Devlieghere <[email protected]> |
[NFC] Remove ASCII lines from comments
A lot of comments in LLDB are surrounded by an ASCII line to delimit the begging and end of the comment.
Its use is not really consistent across the code base
[NFC] Remove ASCII lines from comments
A lot of comments in LLDB are surrounded by an ASCII line to delimit the begging and end of the comment.
Its use is not really consistent across the code base, sometimes the lines are longer, sometimes they are shorter and sometimes they are omitted. Furthermore, it looks kind of weird with the 80 column limit, where the comment actually extends past the line, but not by much. Furthermore, when /// is used for Doxygen comments, it looks particularly odd. And when // is used, it incorrectly gives the impression that it's actually a Doxygen comment.
I assume these lines were added to improve distinguishing between comments and code. However, given that todays editors and IDEs do a great job at highlighting comments, I think it's worth to drop this for the sake of consistency. The alternative is fixing all the inconsistencies, which would create a lot more churn.
Differential revision: https://reviews.llvm.org/D60508
llvm-svn: 358135
show more ...
|
|
Revision tags: llvmorg-8.0.0, llvmorg-8.0.0-rc5 |
|
| #
f05b42e9 |
| 11-Mar-2019 |
Adrian Prantl <[email protected]> |
Bring Doxygen comment syntax in sync with LLVM coding style. This changes '@' prefix to '\'.
llvm-svn: 355841
|
|
Revision tags: llvmorg-8.0.0-rc4, llvmorg-8.0.0-rc3, 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 ...
|
| #
181b823b |
| 14-Dec-2018 |
Pavel Labath <[email protected]> |
Move Broadcaster+Listener+Event combo from Core into Utility
Summary: These are general purpose "utility" classes, whose functionality is not debugger-specific in any way. As such, I believe they be
Move Broadcaster+Listener+Event combo from Core into Utility
Summary: These are general purpose "utility" classes, whose functionality is not debugger-specific in any way. As such, I believe they belong in the Utility module.
This doesn't break any particular dependency (yet), but it reduces the number of Core dependencies across the board.
Reviewers: zturner, jingham, teemperor, clayborg
Subscribers: mgorny, lldb-commits
Differential Revision: https://reviews.llvm.org/D55361
llvm-svn: 349157
show more ...
|
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3 |
|
| #
ceff6644 |
| 11-Nov-2018 |
Jonas Devlieghere <[email protected]> |
Remove header grouping comments.
This patch removes the comments grouping header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdate
Remove header grouping comments.
This patch removes the comments grouping header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdates and burdensome to maintain.
llvm-svn: 346626
show more ...
|
|
Revision tags: 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 |
|
| #
d8f460e8 |
| 02-May-2018 |
Adrian Prantl <[email protected]> |
Enable AUTOBRIEF in doxygen configuration.
This brings the LLDB configuration closer to LLVM's and removes visual clutter in the source code by removing the @brief commands from comments.
This patc
Enable AUTOBRIEF in doxygen configuration.
This brings the LLDB configuration closer to LLVM's and removes visual clutter in the source code by removing the @brief commands from comments.
This patch also reflows the paragraphs in all doxygen comments.
See also https://reviews.llvm.org/D46290.
Differential Revision: https://reviews.llvm.org/D46321
llvm-svn: 331373
show more ...
|
|
Revision tags: 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 |
|
| #
fb1a0a0d |
| 06-Mar-2017 |
Zachary Turner <[email protected]> |
Move many other files from Core -> Utility.
llvm-svn: 297043
|
|
Revision tags: llvmorg-4.0.0-rc3, llvmorg-4.0.0-rc2, 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, llvmorg-3.8.1, llvmorg-3.8.1-rc1 |
|
| #
16ff8604 |
| 18-May-2016 |
Saleem Abdulrasool <[email protected]> |
remove use of Mutex in favour of std::{,recursive_}mutex
This is a pretty straightforward first pass over removing a number of uses of Mutex in favor of std::mutex or std::recursive_mutex. The probl
remove use of Mutex in favour of std::{,recursive_}mutex
This is a pretty straightforward first pass over removing a number of uses of Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there are interfaces which take Mutex::Locker & to lock internal locks. This patch cleans up most of the easy cases. The only non-trivial change is in CommandObjectTarget.cpp where a Mutex::Locker was split into two.
llvm-svn: 269877
show more ...
|
|
Revision tags: llvmorg-3.8.0, llvmorg-3.8.0-rc3, llvmorg-3.8.0-rc2, llvmorg-3.8.0-rc1, llvmorg-3.7.1, llvmorg-3.7.1-rc2, llvmorg-3.7.1-rc1 |
|
| #
fb2eec7e |
| 17-Oct-2015 |
Eugene Zelenko <[email protected]> |
[LLDB] Fix Clang-tidy modernize-use-override warnings in some headers in source/Plugins/Process/Utility; other minor fixes.
Differential Revision: http://reviews.llvm.org/D13830
llvm-svn: 250593
|
|
Revision tags: llvmorg-3.7.0, llvmorg-3.7.0-rc4, llvmorg-3.7.0-rc3, llvmorg-3.7.0-rc2, llvmorg-3.7.0-rc1, llvmorg-3.6.2, llvmorg-3.6.2-rc1, llvmorg-3.6.1, llvmorg-3.6.1-rc1, llvmorg-3.5.2, llvmorg-3.5.2-rc1, llvmorg-3.6.0, llvmorg-3.6.0-rc4, llvmorg-3.6.0-rc3, llvmorg-3.6.0-rc2, llvmorg-3.6.0-rc1, llvmorg-3.5.1, llvmorg-3.5.1-rc2, llvmorg-3.5.1-rc1 |
|
| #
beed821f |
| 04-Sep-2014 |
Kuba Brecka <[email protected]> |
ASan malloc/free history threads
Reviewed at http://reviews.llvm.org/D4596
llvm-svn: 217116
|
|
Revision tags: llvmorg-3.5.0, llvmorg-3.5.0-rc4, llvmorg-3.5.0-rc3, llvmorg-3.5.0-rc2, llvmorg-3.5.0-rc1, llvmorg-3.4.2, llvmorg-3.4.2-rc1, llvmorg-3.4.1, llvmorg-3.4.1-rc2, llvmorg-3.4.1-rc1 |
|
| #
2fd83355 |
| 05-Feb-2014 |
Jason Molenda <[email protected]> |
Change the Mac OS X SystemRuntime plugin from using the placeholder libldi library to collect extended backtrace information; switch to the libBacktraceRecording library and its APIs. Complete the w
Change the Mac OS X SystemRuntime plugin from using the placeholder libldi library to collect extended backtrace information; switch to the libBacktraceRecording library and its APIs. Complete the work of adding QueueItems to Queues and allow for the QueueItems to be interrogated about their extended backtraces in turn.
There's still cleanup and documentation to do on this code but the code is functional and I it's a good time to get the work-in-progress checked in. <rdar://problem/15314027>
llvm-svn: 200822
show more ...
|
|
Revision tags: llvmorg-3.4.0, llvmorg-3.4.0-rc3, llvmorg-3.4.0-rc2, llvmorg-3.4.0-rc1 |
|
| #
a6e9130d |
| 19-Nov-2013 |
Jason Molenda <[email protected]> |
Add logging for the SB API which creates extended threads.
Take a stab at fixing the too-soon freeing of the extended backtrace thread list in Process. <rdar://problem/15496603>
llvm-svn: 195104
|
| #
8ee9cb58 |
| 16-Nov-2013 |
Jason Molenda <[email protected]> |
Add a new SBThread::GetExtendedBacktraceOriginatingIndexID() method (and same thing to Thread base class) which can be used when looking at an ExtendedBacktrace thread; it will try to find the IndexI
Add a new SBThread::GetExtendedBacktraceOriginatingIndexID() method (and same thing to Thread base class) which can be used when looking at an ExtendedBacktrace thread; it will try to find the IndexID() of the original thread that was executing this backtrace when it was recorded. If lldb can't find a record of that thread, it will return the same value as IndexID() for the ExtendedBacktrace thread.
llvm-svn: 194912
show more ...
|
| #
a7b5afa9 |
| 15-Nov-2013 |
Jason Molenda <[email protected]> |
Commit a work-in-progress system runtime for Mac OS X which won't do anything right now. Add a few new methods to the Thread base class which HistoryThread needs. I think I updated all the CMakeLi
Commit a work-in-progress system runtime for Mac OS X which won't do anything right now. Add a few new methods to the Thread base class which HistoryThread needs. I think I updated all the CMakeLists files correctly for the new plugin.
llvm-svn: 194756
show more ...
|
| #
02706c32 |
| 08-Nov-2013 |
Jason Molenda <[email protected]> |
Add History subclasses for Thread, Unwind, RegisterContext. Still working out some of the details of these classes but I wanted to get the overall structure checked in. <rdar://problem/15314068>
l
Add History subclasses for Thread, Unwind, RegisterContext. Still working out some of the details of these classes but I wanted to get the overall structure checked in. <rdar://problem/15314068>
llvm-svn: 194245
show more ...
|