|
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 |
|
| #
c34698a8 |
| 03-Feb-2022 |
Pavel Labath <[email protected]> |
[lldb] Rename Logging.h to LLDBLog.h and clean up includes
Most of our code was including Log.h even though that is not where the "lldb" log channel is defined (Log.h defines the generic logging inf
[lldb] Rename Logging.h to LLDBLog.h and clean up includes
Most of our code was including Log.h even though that is not where the "lldb" log channel is defined (Log.h defines the generic logging infrastructure). This worked because Log.h included Logging.h, even though it should.
After the recent refactor, it became impossible the two files include each other in this direction (the opposite inclusion is needed), so this patch removes the workaround that was put in place and cleans up all files to include the right thing. It also renames the file to LLDBLog to better reflect its purpose.
show more ...
|
|
Revision tags: llvmorg-15-init |
|
| #
a007a6d8 |
| 31-Jan-2022 |
Pavel Labath <[email protected]> |
[lldb] Convert "LLDB" log channel to the new API
|
|
Revision tags: 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 |
|
| #
e9fe788d |
| 16-Apr-2021 |
Jason Molenda <[email protected]> |
Target::ReadMemory read from read-only binary file Section, not memory
Commiting this patch for Augusto Noronha who is getting set up still.
This patch changes Target::ReadMemory so the default beh
Target::ReadMemory read from read-only binary file Section, not memory
Commiting this patch for Augusto Noronha who is getting set up still.
This patch changes Target::ReadMemory so the default behavior when a read is in a Section that is read-only is to fetch the data from the local binary image, instead of reading it from memory. Update all callers to use their old preferences (the old prefer_file_cache bool) using the new API; we should revisit these calls and see if they really intend to read live memory, or if reading from a read-only Section would be equivalent and important for performance-sensitive cases.
rdar://30634422
Differential revision: https://reviews.llvm.org/D100338
show more ...
|
|
Revision tags: 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 |
|
| #
3169d920 |
| 30-Jul-2020 |
Ted Woodward <[email protected]> |
Remove special Hexagon packet traversal code
On Hexagon, breakpoints need to be on the first instruction of a packet. When the LLVM disassembler for Hexagon returned 32 bit instructions, we needed c
Remove special Hexagon packet traversal code
On Hexagon, breakpoints need to be on the first instruction of a packet. When the LLVM disassembler for Hexagon returned 32 bit instructions, we needed code to find the start of the current packet. Now that the LLVM disassembler for Hexagon returns packets instead of instructions, we always have the first instruction of the packet. Remove the packet traversal code because it can cause problems when the next packet has more than one instruction.
Reviewed By: clayborg
Differential Revision: https://reviews.llvm.org/D84966
show more ...
|
|
Revision tags: 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 |
|
| #
3ccd454c |
| 04-Apr-2020 |
Eric Christopher <[email protected]> |
Fix unused variable, format, and format string warnings. NFC.
|
|
Revision tags: llvmorg-10.0.0, llvmorg-10.0.0-rc6, llvmorg-10.0.0-rc5, llvmorg-10.0.0-rc4 |
|
| #
e4598dc0 |
| 10-Mar-2020 |
Jim Ingham <[email protected]> |
Make ThreadPlans use TID and Process, rather than Thread *.
Differential Revision: https://reviews.llvm.org/D75711
|
| #
04592d5b |
| 05-Mar-2020 |
Pavel Labath <[email protected]> |
[lldb] s/ExecutionContext/Target in Disassembler
Some functions in this file only use the "target" component of an execution context. Adjust the argument lists to reflect that.
This avoids some def
[lldb] s/ExecutionContext/Target in Disassembler
Some functions in this file only use the "target" component of an execution context. Adjust the argument lists to reflect that.
This avoids some defensive null checks and simplifies most of the callers.
show more ...
|
|
Revision tags: llvmorg-10.0.0-rc3, 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 |
|
| #
05c3b36b |
| 20-Dec-2019 |
Pavel Labath <[email protected]> |
[lldb] Fix a -Wreturn-type warning on gcc
|
| #
3c6554be |
| 17-Dec-2019 |
Raphael Isemann <[email protected]> |
[lldb] Fix unused variable warning in ThreadPlanStepRange.cpp
This was added in 434905b97d961531286d4b49c7ee1969f7cbea0e. Remove it to fix the compiler warnings for this.
|
| #
434905b9 |
| 17-Dec-2019 |
Jim Ingham <[email protected]> |
Run all threads when extending a next range over a call.
If you don't do this you end up running arbitrary code with only one thread allowed to run, which can cause deadlocks.
<rdar://problem/56422
Run all threads when extending a next range over a call.
If you don't do this you end up running arbitrary code with only one thread allowed to run, which can cause deadlocks.
<rdar://problem/56422478>
Differential Revision: https://reviews.llvm.org/D71440
show more ...
|
|
Revision tags: 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 |
|
| #
63e5fb76 |
| 24-Jul-2019 |
Jonas Devlieghere <[email protected]> |
[Logging] Replace Log::Printf with LLDB_LOG macro (NFC)
This patch replaces explicit calls to log::Printf with the new LLDB_LOGF macro. The macro is similar to LLDB_LOG but supports printf-style for
[Logging] Replace Log::Printf with LLDB_LOG macro (NFC)
This patch replaces explicit calls to log::Printf with the new LLDB_LOGF macro. The macro is similar to LLDB_LOG but supports printf-style format strings, instead of formatv-style format strings.
So instead of writing:
if (log) log->Printf("%s\n", str);
You'd write:
LLDB_LOG(log, "%s\n", str);
This change was done mechanically with the command below. I replaced the spurious if-checks with vim, since I know how to do multi-line replacements with it.
find . -type f -name '*.cpp' -exec \ sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" +
Differential revision: https://reviews.llvm.org/D65128
llvm-svn: 366936
show more ...
|
|
Revision tags: 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 |
|
| #
df225764 |
| 09-May-2019 |
Greg Clayton <[email protected]> |
Improve step over performance by not stopping at branches that are function calls and stepping into and them out of each one
Currently when we single step over a source line, we run and stop at ever
Improve step over performance by not stopping at branches that are function calls and stepping into and them out of each one
Currently when we single step over a source line, we run and stop at every branch in the source line range. We can reduce the number of times we stop when stepping over by figuring out if any of these branches are function calls, and if so, ignore these branches. Since we are stepping over we can safely ignore these calls since they will return to the next instruction. Currently the step logic would stop at those branches (1st stop), single step into the branch (2nd stop), and then set a breakpoint at the return address (3rd stop), and then continue.
Differential Revision: https://reviews.llvm.org/D58678
llvm-svn: 360375
show more ...
|
| #
8a777920 |
| 06-May-2019 |
Greg Clayton <[email protected]> |
Include inlined functions when figuring out a contiguous address range
Checking this in for Antonio Afonso:
This diff changes the function LineEntry::GetSameLineContiguousAddressRange so that it al
Include inlined functions when figuring out a contiguous address range
Checking this in for Antonio Afonso:
This diff changes the function LineEntry::GetSameLineContiguousAddressRange so that it also includes function calls that were inlined at the same line of code.
My motivation is to decrease the step over time of lines that heavly rely on inlined functions. I have multiple examples in the code base I work that makes a step over stop 20 or mote times internally. This can easly had up to step overs that take >500ms which I was able to lower to 25ms with this new strategy.
The reason the current code is not extending the address range beyond an inlined function is because when we resolve the symbol at the next address of the line entry we will get the entry line corresponding to where the original code for the inline function lives, making us barely extend the range. This then will end up on a step over having to stop multiple times everytime there's an inlined function.
To check if the range is an inlined function at that line I also get the block associated with the next address and check if there is a parent block with a call site at the line we're trying to extend.
To check this I created a new function in Block called GetContainingInlinedBlockWithCallSite that does exactly that. I also added a new function to Declaration for convinence of checking file/line named CompareFileAndLine.
To avoid potential issues when extending an address range I added an Extend function that extends the range by the AddressRange given as an argument. This function returns true to indicate sucess when the rage was agumented, false otherwise (e.g.: the ranges are not connected). The reason I do is to make sure that we're not just blindly extending complete_line_range by whatever GetByteSize() we got. If for some reason the ranges are not connected or overlap, or even 0, this could be an issue.
I also added a unit tests for this change and include the instructions on the test itself on how to generate the yaml file I use for testing.
Differential Revision: https://reviews.llvm.org/D61292
llvm-svn: 360071
show more ...
|
| #
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, 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 ...
|
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3 |
|
| #
e103ae92 |
| 15-Nov-2018 |
Jonas Devlieghere <[email protected]> |
Add setting to require hardware breakpoints.
When debugging read-only memory we cannot use software breakpoint. We already have support for hardware breakpoints and users can specify them with `-H`.
Add setting to require hardware breakpoints.
When debugging read-only memory we cannot use software breakpoint. We already have support for hardware breakpoints and users can specify them with `-H`. However, there's no option to force LLDB to use hardware breakpoints internally, for example while stepping.
This patch adds a setting target.require-hardware-breakpoint that forces LLDB to always use hardware breakpoints. Because hardware breakpoints are a limited resource and can fail to resolve, this patch also extends error handling in thread plans, where breakpoints are used for stepping.
Differential revision: https://reviews.llvm.org/D54221
llvm-svn: 346920
show more ...
|
| #
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 |
|
| #
05097246 |
| 30-Apr-2018 |
Adrian Prantl <[email protected]> |
Reflow paragraphs in comments.
This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to r
Reflow paragraphs in comments.
This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read.
FYI, the script I used was:
import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue
if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2)
continue
if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = ""
out.write(line)
os.rename(tmp, sys.argv[1])
Differential Revision: https://reviews.llvm.org/D46144
llvm-svn: 331197
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 |
|
| #
6f9e6901 |
| 03-Mar-2017 |
Zachary Turner <[email protected]> |
Move Log from Core -> Utility.
All references to Host and Core have been removed, so this class can now safely be lowered into Utility.
Differential Revision: https://reviews.llvm.org/D30559
llvm-
Move Log from Core -> Utility.
All references to Host and Core have been removed, so this class can now safely be lowered into Utility.
Differential Revision: https://reviews.llvm.org/D30559
llvm-svn: 296909
show more ...
|
|
Revision tags: llvmorg-4.0.0-rc3 |
|
| #
86aaa8a2 |
| 15-Feb-2017 |
Boris Ulasevich <[email protected]> |
Bug 30863 - Step doesn't stop with conditional breakpoint on the next line Differential Revisions: https://reviews.llvm.org/D26497 (committed r290168, temporary reverted r290197) https://reviews.
Bug 30863 - Step doesn't stop with conditional breakpoint on the next line Differential Revisions: https://reviews.llvm.org/D26497 (committed r290168, temporary reverted r290197) https://reviews.llvm.org/D28945 (fix for Ubuntu tests fail) https://reviews.llvm.org/D29909 (fix for TestCallThatThrows test fail)
llvm-svn: 295168
show more ...
|
|
Revision tags: 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 ...
|
| #
67346ca9 |
| 27-Jan-2017 |
Boris Ulasevich <[email protected]> |
Unroll r292930 due to TestCallThatThrows test fail is not fixed in reasonable time.
llvm-svn: 293269
|
| #
29a8eba9 |
| 24-Jan-2017 |
Boris Ulasevich <[email protected]> |
Bug 30863 - Step doesn't stop with conditional breakpoint on the next line Differential Revisions: https://reviews.llvm.org/D26497 (committed r290168, temporary reverted r290197) https://reviews.
Bug 30863 - Step doesn't stop with conditional breakpoint on the next line Differential Revisions: https://reviews.llvm.org/D26497 (committed r290168, temporary reverted r290197) https://reviews.llvm.org/D28945 (fix for Ubuntu tests fail)
llvm-svn: 292930
show more ...
|
|
Revision tags: llvmorg-4.0.0-rc1 |
|
| #
9cc1e196 |
| 20-Dec-2016 |
Boris Ulasevich <[email protected]> |
Rollback my commit r290168 to fix linux tests failure. I'll be back!
llvm-svn: 290197
|