|
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, 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 |
|
| #
fd2433e1 |
| 02-Jul-2021 |
Jonas Devlieghere <[email protected]> |
[lldb] Replace default bodies of special member functions with = default;
Replace default bodies of special member functions with = default;
$ run-clang-tidy.py -header-filter='lldb' -checks='-*,mo
[lldb] Replace default bodies of special member functions with = default;
Replace default bodies of special member functions with = default;
$ run-clang-tidy.py -header-filter='lldb' -checks='-*,modernize-use-equals-default' -fix ,
https://clang.llvm.org/extra/clang-tidy/checks/modernize-use-equals-default.html
Differential revision: https://reviews.llvm.org/D104041
show more ...
|
|
Revision tags: llvmorg-12.0.1, llvmorg-12.0.1-rc4, llvmorg-12.0.1-rc3, llvmorg-12.0.1-rc2 |
|
| #
76e47d48 |
| 26-May-2021 |
Raphael Isemann <[email protected]> |
[lldb][NFC] Use C++ versions of the deprecated C standard library headers
The C headers are deprecated so as requested in D102845, this is replacing them all with their (not deprecated) C++ equivale
[lldb][NFC] Use C++ versions of the deprecated C standard library headers
The C headers are deprecated so as requested in D102845, this is replacing them all with their (not deprecated) C++ equivalent.
Reviewed By: shafik
Differential Revision: https://reviews.llvm.org/D103084
show more ...
|
|
Revision tags: 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 |
|
| #
057efa99 |
| 11-Feb-2021 |
Adrian Prantl <[email protected]> |
Make the error condition in Value::ValueType explicit (NFC)
The comment for ValueType claims that all values <1 are errors, but not all switch statements take this into account. This patch introduce
Make the error condition in Value::ValueType explicit (NFC)
The comment for ValueType claims that all values <1 are errors, but not all switch statements take this into account. This patch introduces an explicit Error case and deletes all default: cases, so we get warned about incomplete switch coverage.
https://reviews.llvm.org/D96537
show more ...
|
|
Revision tags: 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 |
|
| #
79d16764 |
| 05-Nov-2020 |
Raphael Isemann <[email protected]> |
[lldb][NFC] Fix compiler warnings after removal of eValueTypeVector
5d64574301836c4c17127794121d49a62d24f803 removes this enum value and now all the switch statements that previously relied on handl
[lldb][NFC] Fix compiler warnings after removal of eValueTypeVector
5d64574301836c4c17127794121d49a62d24f803 removes this enum value and now all the switch statements that previously relied on handling this in the 'default' branch are causes compiler warnings due to redundant default cases.
This just removes the now unreachable code in there.
show more ...
|
| #
97ca9ca1 |
| 12-Oct-2020 |
Pavel Labath <[email protected]> |
[lldb] Fix bitfield "frame var" for pointers (pr47743)
Displaying large packed bitfields did not work if one was accessing them through a pointer, and he used the "->" notation ("[0]." notation is f
[lldb] Fix bitfield "frame var" for pointers (pr47743)
Displaying large packed bitfields did not work if one was accessing them through a pointer, and he used the "->" notation ("[0]." notation is fine). The reason for that is that implicit dereference in -> is plumbed all the way down to ValueObjectChild::UpdateValue, where the process of fetching the child value was forked for this flag. The bitfield "sliding" code was implemented only for the branch which did not require dereferencing.
This patch restructures the function to avoid this mistake. Processing now happens in two stages. - first the parent is dereferenced (if needed) - then the child value is computed (this step includes sliding and is common for both branches)
Differential Revision: https://reviews.llvm.org/D89236
show more ...
|
| #
19d64138 |
| 07-Oct-2020 |
Pavel Labath <[email protected]> |
[lldb] Fix "frame var" for large bitfields
The problem here is in the "sliding" code in ValueObjectChild::UpdateValue. It modifies m_bitfield_bit_offset and m_value to ensure the bitfield value fits
[lldb] Fix "frame var" for large bitfields
The problem here is in the "sliding" code in ValueObjectChild::UpdateValue. It modifies m_bitfield_bit_offset and m_value to ensure the bitfield value fits the window given by the underlying type.
However, this is broken next time UpdateValue is called, because it updates the m_value value from the parent. However, the value cannot be slid again because the m_bitfield_bit_offset is already modified.
It seems this can happen only under specific circumstances. One way to trigger is is to run an expression which can be interpreted (jitting it causes a new StackFrame and ValueObject variables to be created).
I fix this bug by modifying m_byte_offset instead of m_scalar, and ensuring the changes are folded into m_scalar regardless of how many times UpdateValue is called.
Differential Revision: https://reviews.llvm.org/D88992
show more ...
|
|
Revision tags: 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 |
|
| #
25bbceb0 |
| 13-Aug-2020 |
shafik <[email protected]> |
[LLDB] Fix how ValueObjectChild handles bit-fields stored in a Scalar in UpdateValue()
When bit-field data was stored in a Scalar in ValueObjectChild during UpdateValue() it was extracting the bit-f
[LLDB] Fix how ValueObjectChild handles bit-fields stored in a Scalar in UpdateValue()
When bit-field data was stored in a Scalar in ValueObjectChild during UpdateValue() it was extracting the bit-field value. Later on in lldb_private::DumpDataExtractor(…) we were again attempting to extract the bit-field. Which would then not obtain the correct value. This will remove the extra extraction in UpdateValue(). We hit this specific case when values are passed in registers, which we could only reproduce in an optimized build.
Differential Revision: https://reviews.llvm.org/D85376
show more ...
|
|
Revision tags: llvmorg-11.0.0-rc1 |
|
| #
db203e02 |
| 27-Jul-2020 |
Raphael Isemann <[email protected]> |
[lldb] Modernize away some snprintf calls
Reviewers: #lldb, JDevlieghere
Reviewed By: #lldb, JDevlieghere
Subscribers: JDevlieghere
Differential Revision: https://reviews.llvm.org/D84530
|
|
Revision tags: 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, llvmorg-10.0.0-rc2 |
|
| #
30ce956a |
| 12-Feb-2020 |
Raphael Isemann <[email protected]> |
[lldb][NFC] Remove GetConstTypeName and GetConstQualifiedTypeName from CompilerType
Beside these two functions just being wrappers around GetTypeName they are also just a leftover from migrating the
[lldb][NFC] Remove GetConstTypeName and GetConstQualifiedTypeName from CompilerType
Beside these two functions just being wrappers around GetTypeName they are also just a leftover from migrating the CompilerType interface to ConstString.
show more ...
|
|
Revision tags: 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 |
|
| #
d9cbd2ac |
| 08-Aug-2019 |
Adrian Prantl <[email protected]> |
Remove unused and undocumented data_offset parameter (NFC)
Value::GetValueAsData() takes an undocumented parameter called data_offset that is always 0.
Differential Revision: https://reviews.llvm.o
Remove unused and undocumented data_offset parameter (NFC)
Value::GetValueAsData() takes an undocumented parameter called data_offset that is always 0.
Differential Revision: https://reviews.llvm.org/D65910
llvm-svn: 368330
show more ...
|
| #
f81d6fe7 |
| 07-Aug-2019 |
Adrian Prantl <[email protected]> |
Adjust a ValueObjectChild's offset when the child is a bitfield
If a bitfield doesn't fit into the child_byte_size'd window at child_byte_offset, move the window forward until it fits. The problem
Adjust a ValueObjectChild's offset when the child is a bitfield
If a bitfield doesn't fit into the child_byte_size'd window at child_byte_offset, move the window forward until it fits. The problem here is that Value has no notion of bitfields and thus the Value's DataExtractor is sized like the bitfields CompilerType; a sequence of bitfields, however, can be larger than their underlying type.
This was not in the big-endian-derived DWARF 2 bitfield attributes because their offsets were counted from the end of the window, so they always fit.
rdar://problem/53132189
Differential Revision: https://reviews.llvm.org/D65492
llvm-svn: 368226
show more ...
|
|
Revision tags: 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, llvmorg-8.0.0, llvmorg-8.0.0-rc5, llvmorg-8.0.0-rc4 |
|
| #
0e4c4821 |
| 06-Mar-2019 |
Adrian Prantl <[email protected]> |
Pass ConstString by value (NFC)
My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed.
ConstString has exactly one const char * data member, s
Pass ConstString by value (NFC)
My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed.
ConstString has exactly one const char * data member, so passing a ConstString by reference is not any more efficient than copying it by value. In both cases a single pointer is passed. But passing it by value makes it harder to accidentally return the address of a local object.
(This fixes rdar://problem/48640859 for the Apple folks)
Differential Revision: https://reviews.llvm.org/D59030
llvm-svn: 355553
show more ...
|
|
Revision tags: 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 ...
|
| #
03bd1838 |
| 19-Dec-2018 |
Adrian Prantl <[email protected]> |
Simplify code for readability. (NFC)
llvm-svn: 349700
|
| #
a6682a41 |
| 15-Dec-2018 |
Jonas Devlieghere <[email protected]> |
Simplify Boolean expressions
This patch simplifies boolean expressions acorss LLDB. It was generated using clang-tidy with the following command:
run-clang-tidy.py -checks='-*,readability-simplify-
Simplify Boolean expressions
This patch simplifies boolean expressions acorss LLDB. It was generated using clang-tidy with the following command:
run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD
Differential revision: https://reviews.llvm.org/D55584
llvm-svn: 349215
show more ...
|
|
Revision tags: llvmorg-7.0.1, llvmorg-7.0.1-rc3 |
|
| #
672d2c12 |
| 11-Nov-2018 |
Jonas Devlieghere <[email protected]> |
Remove comments after header includes.
This patch removes the comments following the header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are of
Remove comments after header includes.
This patch removes the comments following the header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdates and burdensome to maintain.
Differential revision: https://reviews.llvm.org/D54385
llvm-svn: 346625
show more ...
|
| #
eca07c59 |
| 05-Nov-2018 |
Adrian Prantl <[email protected]> |
Fix (and improve) the support for C99 variable length array types
Clang recently improved its DWARF support for C VLA types. The DWARF now looks like this:
0x00000051: DW_TAG_variable [4]
Fix (and improve) the support for C99 variable length array types
Clang recently improved its DWARF support for C VLA types. The DWARF now looks like this:
0x00000051: DW_TAG_variable [4] DW_AT_location( fbreg -32 ) DW_AT_name( "__vla_expr" ) DW_AT_type( {0x000000d3} ( long unsigned int ) ) DW_AT_artificial( true ) ... 0x000000da: DW_TAG_array_type [10] * DW_AT_type( {0x000000cc} ( int ) )
0x000000df: DW_TAG_subrange_type [11] DW_AT_type( {0x000000e9} ( __ARRAY_SIZE_TYPE__ ) ) DW_AT_count( {0x00000051} )
Without this patch LLDB will naively interpret the DIE offset 0x51 as the static size of the array, which is clearly wrong. This patch extends ValueObject::GetNumChildren to query the dynamic properties of incomplete array types.
See the testcase for an example:
4 int foo(int a) { 5 int vla[a]; 6 for (int i = 0; i < a; ++i) 7 vla[i] = i; 8 -> 9 pause(); // break here 10 return vla[a-1]; 11 }
(lldb) fr v vla (int []) vla = ([0] = 0, [1] = 1, [2] = 2, [3] = 3) (lldb) quit
rdar://problem/21814005
Differential Revision: https://reviews.llvm.org/D53530
llvm-svn: 346165
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 |
|
| #
d821c997 |
| 07-Aug-2018 |
Pavel Labath <[email protected]> |
Move RegisterValue,Scalar,State from Core to Utility
These three classes have no external dependencies, but they are used from various low-level APIs. Moving them down to Utility improves overall co
Move RegisterValue,Scalar,State from Core to Utility
These three classes have no external dependencies, but they are used from various low-level APIs. Moving them down to Utility improves overall code layering (although it still does not break any particular dependency completely).
The XCode project will need to be updated after this change.
Differential Revision: https://reviews.llvm.org/D49740
llvm-svn: 339127
show more ...
|
|
Revision tags: 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 |
|
| #
97206d57 |
| 12-May-2017 |
Zachary Turner <[email protected]> |
Rename Error -> Status.
This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list.
A change of this magnitude cannot easily be done without find and replace, but that h
Rename Error -> Status.
This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list.
A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious.
llvm-svn: 302872
show more ...
|