| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
[NFC][Py Reformat] Reformat python files in lldb This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with black (23.1.0). If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run git checkout --ours <yourfile> and then reformat it with black. RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style Differential revision: https://reviews.llvm.org/D151460 | 3 年前 | |
[NFC][Py Reformat] Reformat python files in lldb This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with black (23.1.0). If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run git checkout --ours <yourfile> and then reformat it with black. RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style Differential revision: https://reviews.llvm.org/D151460 | 3 年前 | |
[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 | 7 年前 | |
[lldb] NFC remove DISALLOW_COPY_AND_ASSIGN Summary: This is how I applied my clang-tidy check (see https://reviews.llvm.org/D80531) in order to remove DISALLOW_COPY_AND_ASSIGN and have deleted copy ctors and deleted assignment operators instead. lang=bash grep DISALLOW_COPY_AND_ASSIGN /opt/notnfs/kkleine/llvm/lldb -r -l | sort | uniq > files for i in $(cat files); do clang-tidy \ --checks="-*,modernize-replace-disallow-copy-and-assign-macro" \ --format-style=LLVM \ --header-filter=.* \ --fix \ -fix-errors \ $i; done Reviewers: espindola, labath, aprantl, teemperor Reviewed By: labath, aprantl, teemperor Subscribers: teemperor, aprantl, labath, emaste, sbc100, aheejin, MaskRay, arphaman, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D80543 | 6 年前 | |
[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 | 7 年前 | |
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 | 7 年前 | |
Revert "[lldb] Introduce ScriptedFrameProvider for real threads" (#167662) The new test fails on x86 and arm64 public macOS bots: 09:27:59 ====================================================================== 09:27:59 FAIL: test_append_frames (TestScriptedFrameProvider.ScriptedFrameProviderTestCase) 09:27:59 Test that we can add frames after real stack. 09:27:59 ---------------------------------------------------------------------- 09:27:59 Traceback (most recent call last): 09:27:59 File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py", line 122, in test_append_frames 09:27:59 self.assertEqual(new_frame_count, original_frame_count + 1) 09:27:59 AssertionError: 5 != 6 09:27:59 Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang 09:27:59 ====================================================================== 09:27:59 FAIL: test_applies_to_thread (TestScriptedFrameProvider.ScriptedFrameProviderTestCase) 09:27:59 Test that applies_to_thread filters which threads get the provider. 09:27:59 ---------------------------------------------------------------------- 09:27:59 Traceback (most recent call last): 09:27:59 File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py", line 218, in test_applies_to_thread 09:27:59 self.assertEqual( 09:27:59 AssertionError: 5 != 1 : Thread with ID 1 should have 1 synthetic frame 09:27:59 Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang 09:27:59 ====================================================================== 09:27:59 FAIL: test_prepend_frames (TestScriptedFrameProvider.ScriptedFrameProviderTestCase) 09:27:59 Test that we can add frames before real stack. 09:27:59 ---------------------------------------------------------------------- 09:27:59 Traceback (most recent call last): 09:27:59 File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py", line 84, in test_prepend_frames 09:27:59 self.assertEqual(new_frame_count, original_frame_count + 2) 09:27:59 AssertionError: 5 != 7 09:27:59 Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang 09:27:59 ====================================================================== 09:27:59 FAIL: test_remove_frame_provider_by_id (TestScriptedFrameProvider.ScriptedFrameProviderTestCase) 09:27:59 Test that RemoveScriptedFrameProvider removes a specific provider by ID. 09:27:59 ---------------------------------------------------------------------- 09:27:59 Traceback (most recent call last): 09:27:59 File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py", line 272, in test_remove_frame_provider_by_id 09:27:59 self.assertEqual(thread.GetNumFrames(), 3, "Should have 3 synthetic frames") 09:27:59 AssertionError: 5 != 3 : Should have 3 synthetic frames 09:27:59 Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang 09:27:59 ====================================================================== 09:27:59 FAIL: test_replace_all_frames (TestScriptedFrameProvider.ScriptedFrameProviderTestCase) 09:27:59 Test that we can replace the entire stack. 09:27:59 ---------------------------------------------------------------------- 09:27:59 Traceback (most recent call last): 09:27:59 File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py", line 41, in test_replace_all_frames 09:27:59 self.assertEqual(thread.GetNumFrames(), 3, "Should have 3 synthetic frames") 09:27:59 AssertionError: 5 != 3 : Should have 3 synthetic frames 09:27:59 Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang 09:27:59 ====================================================================== 09:27:59 FAIL: test_scripted_frame_objects (TestScriptedFrameProvider.ScriptedFrameProviderTestCase) 09:27:59 Test that provider can return ScriptedFrame objects. 09:27:59 ---------------------------------------------------------------------- 09:27:59 Traceback (most recent call last): 09:27:59 File "/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/llvm-project/lldb/test/API/functionalities/scripted_frame_provider/TestScriptedFrameProvider.py", line 159, in test_scripted_frame_objects 09:27:59 self.assertEqual(frame0.GetFunctionName(), "custom_scripted_frame_0") 09:27:59 AssertionError: 'thread_func(int)' != 'custom_scripted_frame_0' 09:27:59 - thread_func(int) 09:27:59 + custom_scripted_frame_0 09:27:59 09:27:59 Config=arm64-/Users/ec2-user/jenkins/workspace/llvm.org/as-lldb-cmake/lldb-build/bin/clang 09:27:59 ---------------------------------------------------------------------- 09:27:59 Ran 6 tests in 14.242s 09:27:59 09:27:59 FAILED (failures=6) Reverts llvm/llvm-project#161870 | 8 个月前 | |
[NFC][Py Reformat] Reformat python files in lldb This is an ongoing series of commits that are reformatting our Python code. Reformatting is done with black (23.1.0). If you end up having problems merging this commit because you have made changes to a python file, the best way to handle that is to run git checkout --ours <yourfile> and then reformat it with black. RFC: https://discourse.llvm.org/t/rfc-document-and-standardize-python-code-style Differential revision: https://reviews.llvm.org/D151460 | 3 年前 | |
[lldb][examples] Use "chr" in CFString.py Python3 removed "unichr" when string encoding was changed, so this code tried to import that then defaulted to "chr" if it couldn't. Since LLVM requires >=3.8 we can use "chr" directly. | 9 个月前 | |
[lldb] Fix StdUnorderedMapSynthProvider for GCC (#164251) This patch adds small workaround for [issue](https://github.com/llvm/llvm-project/issues/152504). It looks like code compiled with gcc has lack of some important debug information (e.g. DW_TAG_template_type_parameter for allocator). Example code: cpp #include <unordered_map> int main() { std::unordered_map<int, int> map = { {1, 2} }; return 0; } Output from llvm-dwarfdump for code compiled by GCC or Clang. I used system GCC (13.3.0) and Clang (18.1.3) on Ubuntu 24.04 (WSL). GCC: 0x00001fcd: DW_TAG_class_type DW_AT_name ("allocator<std::pair<int const, int> >") DW_AT_byte_size (0x01) DW_AT_decl_file ("/usr/include/c++/13/bits/allocator.h") DW_AT_decl_line (130) DW_AT_decl_column (11) DW_AT_sibling (0x0000207c) 0x00001fda: DW_TAG_inheritance DW_AT_type (0x00001d0a "std::__new_allocator<std::pair<int const, int> >") DW_AT_data_member_location (0) DW_AT_accessibility (DW_ACCESS_public) 0x00001fe0: DW_TAG_subprogram DW_AT_external (true) DW_AT_name ("allocator") DW_AT_decl_file ("/usr/include/c++/13/bits/allocator.h") DW_AT_decl_line (163) DW_AT_decl_column (7) DW_AT_linkage_name ("_ZNSaISt4pairIKiiEEC4Ev") DW_AT_accessibility (DW_ACCESS_public) DW_AT_declaration (true) DW_AT_object_pointer (0x00001ff4) DW_AT_sibling (0x00001ffa) 0x00001ff4: DW_TAG_formal_parameter DW_AT_type (0x00004eb9 "std::allocator<std::pair<int const, int> > *") DW_AT_artificial (true) 0x00001ff9: NULL 0x00001ffa: DW_TAG_subprogram DW_AT_external (true) DW_AT_name ("allocator") DW_AT_decl_file ("/usr/include/c++/13/bits/allocator.h") DW_AT_decl_line (167) DW_AT_decl_column (7) DW_AT_linkage_name ("_ZNSaISt4pairIKiiEEC4ERKS2_") DW_AT_accessibility (DW_ACCESS_public) DW_AT_declaration (true) DW_AT_object_pointer (0x0000200e) DW_AT_sibling (0x00002019) 0x0000200e: DW_TAG_formal_parameter DW_AT_type (0x00004eb9 "std::allocator<std::pair<int const, int> > *") DW_AT_artificial (true) 0x00002013: DW_TAG_formal_parameter DW_AT_type (0x00004ec3 "const std::allocator<std::pair<int const, int> > &") 0x00002018: NULL 0x00002019: DW_TAG_subprogram DW_AT_external (true) DW_AT_name ("operator=") DW_AT_decl_file ("/usr/include/c++/13/bits/allocator.h") DW_AT_decl_line (172) DW_AT_decl_column (18) DW_AT_linkage_name ("_ZNSaISt4pairIKiiEEaSERKS2_") DW_AT_type (0x00004ec8 "std::allocator<std::pair<int const, int> > &") DW_AT_accessibility (DW_ACCESS_public) DW_AT_declaration (true) DW_AT_defaulted (DW_DEFAULTED_in_class) DW_AT_object_pointer (0x00002031) DW_AT_sibling (0x0000203c) 0x00002031: DW_TAG_formal_parameter DW_AT_type (0x00004eb9 "std::allocator<std::pair<int const, int> > *") DW_AT_artificial (true) 0x00002036: DW_TAG_formal_parameter DW_AT_type (0x00004ec3 "const std::allocator<std::pair<int const, int> > &") 0x0000203b: NULL 0x0000203c: DW_TAG_subprogram DW_AT_external (true) DW_AT_name ("~allocator") DW_AT_decl_file ("/usr/include/c++/13/bits/allocator.h") DW_AT_decl_line (184) DW_AT_decl_column (7) DW_AT_linkage_name ("_ZNSaISt4pairIKiiEED4Ev") DW_AT_accessibility (DW_ACCESS_public) DW_AT_declaration (true) DW_AT_object_pointer (0x00002050) DW_AT_sibling (0x0000205b) 0x00002050: DW_TAG_formal_parameter DW_AT_type (0x00004eb9 "std::allocator<std::pair<int const, int> > *") DW_AT_artificial (true) 0x00002055: DW_TAG_formal_parameter DW_AT_type (0x00004cab "int") DW_AT_artificial (true) 0x0000205a: NULL Clang: 0x00001a6e: DW_TAG_class_type DW_AT_calling_convention (DW_CC_pass_by_reference) DW_AT_name ("allocator<std::pair<const int, int> >") DW_AT_byte_size (0x01) DW_AT_decl_file ("/usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/allocator.h") DW_AT_decl_line (130) 0x00001a74: DW_TAG_template_type_parameter DW_AT_type (0x00000dec "std::pair<const int, int>") DW_AT_name ("_Tp") 0x00001a7a: DW_TAG_inheritance DW_AT_type (0x00001ad5 "std::__allocator_base<std::pair<const int, int> >") DW_AT_data_member_location (0x00) DW_AT_accessibility (DW_ACCESS_public) 0x00001a81: DW_TAG_subprogram DW_AT_name ("allocator") DW_AT_decl_file ("/usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/allocator.h") DW_AT_decl_line (163) DW_AT_declaration (true) DW_AT_external (true) DW_AT_accessibility (DW_ACCESS_public) 0x00001a86: DW_TAG_formal_parameter DW_AT_type (0x00002dd1 "std::allocator<std::pair<const int, int> > *") DW_AT_artificial (true) 0x00001a8b: NULL 0x00001a8c: DW_TAG_subprogram DW_AT_name ("allocator") DW_AT_decl_file ("/usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/allocator.h") DW_AT_decl_line (167) DW_AT_declaration (true) DW_AT_external (true) DW_AT_accessibility (DW_ACCESS_public) 0x00001a91: DW_TAG_formal_parameter DW_AT_type (0x00002dd1 "std::allocator<std::pair<const int, int> > *") DW_AT_artificial (true) 0x00001a96: DW_TAG_formal_parameter DW_AT_type (0x00002dd6 "const std::allocator<std::pair<const int, int> > &") 0x00001a9b: NULL 0x00001a9c: DW_TAG_subprogram DW_AT_linkage_name ("_ZNSaISt4pairIKiiEEaSERKS2_") DW_AT_name ("operator=") DW_AT_decl_file ("/usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/allocator.h") DW_AT_decl_line (172) DW_AT_type (0x00002de0 "std::allocator<std::pair<const int, int> > &") DW_AT_declaration (true) DW_AT_external (true) DW_AT_accessibility (DW_ACCESS_public) 0x00001aa6: DW_TAG_formal_parameter DW_AT_type (0x00002dd1 "std::allocator<std::pair<const int, int> > *") DW_AT_artificial (true) 0x00001aab: DW_TAG_formal_parameter DW_AT_type (0x00002dd6 "const std::allocator<std::pair<const int, int> > &") 0x00001ab0: NULL 0x00001ab1: DW_TAG_subprogram DW_AT_name ("~allocator") DW_AT_decl_file ("/usr/bin/../lib/gcc/x86_64-linux-gnu/13/../../../../include/c++/13/bits/allocator.h") DW_AT_decl_line (184) DW_AT_declaration (true) DW_AT_external (true) DW_AT_accessibility (DW_ACCESS_public) 0x00001ab6: DW_TAG_formal_parameter DW_AT_type (0x00002dd1 "std::allocator<std::pair<const int, int> > *") DW_AT_artificial (true) 0x00001abb: NULL I propose to add fallback implementation based on type of _M_h. | 8 个月前 | |
[lldb] Remove LLDB session dir and just store test traces in the respective test build directory Test runs log some of their output to files inside the LLDB session dir. This session dir is shared between all tests, so all the tests have to make sure they choose a unique file name inside that directory. We currently choose by default <test-class-name>-<test-method-name> as the log file name. However, that means that if not every test class in the test suite has a unique class name, then we end up with a race condition as two tests will try to write to the same log file. I already tried in D83767 changing the format to use the test file basename instead (which we already require to be unique for some other functionality), but it seems the code for getting the basename didn't work on Windows. This patch instead just changes that dotest stores the log files in the build directory for the current test. We know that directory is unique for this test, so no need to generate some unique file name now. Also removes all the environment vars and parameters related to the now unused session dir. The new log paths now look like this for a failure in 'TestCppOperators: ./lldb-test-build.noindex/lang/cpp/operators/TestCppOperators.test_dwarf/Failure.log ./lldb-test-build.noindex/lang/cpp/operators/TestCppOperators.test_dsym/Failure.log ./lldb-test-build.noindex/lang/cpp/operators/TestCppOperators.test_gmodules/Failure.log ` Reviewed By: labath Differential Revision: https://reviews.llvm.org/D92498 | 5 年前 | |
[lldb][Docs] Additions to debuging LLDB page (#65635) Adds the following: * A note that you can use attaching to debug the right lldb-server process, though there are drawbacks. * A section on debugging the remote protocol. * Reducing bugs, including reducing ptrace bugs to remove the need for LLDB. I've added a standlone ptrace program to the examples folder because: * There's no better place to put it. * Adding it to the page seems like wasting space, and would be harder to update. * I link to Eli Bendersky's classic blog on the subject, but we are safer with our own example as well. * Eli's example is for 32 bit Intel, AArch64 is more common these days. * It's easier to show the software breakpoint steps in code than explain it (though I still do that in the text). * It was living on my laptop not helping anyone so I think it's good to have it upstream for others, including future me. | 2 年前 |
| 文件 | 最后提交记录 | 最后更新时间 |
|---|---|---|
| 3 年前 | ||
| 3 年前 | ||
| 7 年前 | ||
| 6 年前 | ||
| 7 年前 | ||
| 7 年前 | ||
| 8 个月前 | ||
| 3 年前 | ||
| 9 个月前 | ||
| 8 个月前 | ||
| 5 年前 | ||
| 2 年前 |