summaryrefslogtreecommitdiffstats
path: root/lldb/tools/intel-features
Commit message (Collapse)AuthorAgeFilesLines
* [lldb/CMake] Rename LLDB_DISABLE_PYTHON to LLDB_ENABLE_PYTHONJonas Devlieghere2019-12-131-2/+2
| | | | | | | This matches the naming scheme used by LLVM and all the other optional dependencies in LLDB. Differential revision: https://reviews.llvm.org/D71482
* cli-wrapper-mpxtable.cpp: fix file headerFangrui Song2019-07-251-2/+1
| | | | llvm-svn: 366983
* Delete unnecessary copy ctorsFangrui Song2019-05-222-22/+0
| | | | llvm-svn: 361358
* Delete unnecessary copy ctors/copy assignment operatorsFangrui Song2019-05-152-21/+1
| | | | | | It's the simplest and gives the cleanest semantics. llvm-svn: 360762
* C.128 override, virtual keyword handlingRaphael Isemann2019-05-031-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: According to [C128] "Virtual functions should specify exactly one of `virtual`, `override`, or `final`", I've added override where a virtual function is overriden but the explicit `override` keyword was missing. Whenever both `virtual` and `override` were specified, I removed `virtual`. As C.128 puts it: > [...] writing more than one of these three is both redundant and > a potential source of errors. I anticipate a discussion about whether or not to add `override` to destructors but I went for it because of an example in [ISOCPP1000]. Let me repeat the comment for you here: Consider this code: ``` struct Base { virtual ~Base(){} }; struct SubClass : Base { ~SubClass() { std::cout << "It works!\n"; } }; int main() { std::unique_ptr<Base> ptr = std::make_unique<SubClass>(); } ``` If for some odd reason somebody removes the `virtual` keyword from the `Base` struct, the code will no longer print `It works!`. So adding `override` to destructors actively protects us from accidentally breaking our code at runtime. [C128]: https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#c128-virtual-functions-should-specify-exactly-one-of-virtual-override-or-final [ISOCPP1000]: https://github.com/isocpp/CppCoreGuidelines/issues/1000#issuecomment-476951555 Reviewers: teemperor, JDevlieghere, davide, shafik Reviewed By: teemperor Subscribers: kwk, arphaman, kadircet, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D61440 llvm-svn: 359868
* [NFC] Remove ASCII lines from commentsJonas Devlieghere2019-04-102-36/+0
| | | | | | | | | | | | | | | | | | | | | | | 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
* Bring Doxygen comment syntax in sync with LLVM coding style.Adrian Prantl2019-03-112-30/+30
| | | | | | This changes '@' prefix to '\'. llvm-svn: 355841
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-1910-40/+30
| | | | | | | | | | | | | | | | | 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
* Remove header grouping comments.Jonas Devlieghere2018-11-115-6/+0
| | | | | | | | 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
* Enable AUTOBRIEF in doxygen configuration.Adrian Prantl2018-05-022-11/+11
| | | | | | | | | | | | | | 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
* Fix LLVM_LINK_LLVM_DYLIB build (pr35053)Pavel Labath2017-10-311-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | Summary: r316368 broke this build when it introduced a reference to a pthread function to the Utility module. This caused cmake to generate an incorrect link line (wrong order of libs) because it did not see the dependency from Utility to the system libraries. Instead these libraries were being manually added to each final target. This changes moves the dependency management from the individual targets to the lldbUtility module, which is consistent with how llvm does it. The final targets will pick up these libraries as they will be a part of the link interface of the module. Technically, some of these dependencies could go into the host module, as that's where most of the os-specific code is, but I did not try to investigate which ones. Reviewers: zturner, sylvestre.ledru Subscribers: lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D39246 llvm-svn: 316997
* Checking in files accidentally missed in later diffs of revision r310261Abhishek Aggarwal2017-08-082-0/+596
| | | | | | | | | | -- 2 files were missing in this commit which should have been there. These files were submitted initially for review and were reviewed. However, while updating the revision with newer diffs, I accidentally forgot to include them in newer diffs. So commiting now. llvm-svn: 310341
* Fixed build failure for revision r310261Abhishek Aggarwal2017-08-071-0/+6
| | | | | | -- Was failing for Linux llvm-svn: 310270
* Fixed build failure for revision r310261Abhishek Aggarwal2017-08-071-0/+4
| | | | | | -- Build was failing for freebsd llvm-svn: 310266
* Tool for using Intel(R) Processor Trace hardware featureAbhishek Aggarwal2017-08-0721-0/+3128
Summary: 1. Provide single library for all Intel specific hardware features instead of individual libraries for each feature 2. Added Intel(R) Processor Trace hardware feature in this single library. Details about the tool implementing this feature is as follows: Tool developed on top of LLDB to provide its users the execution trace of the debugged inferiors. Tool's API are exposed as C++ object oriented interface in a shared library. API are designed especially to be easily integrable with IDEs providing LLDB as an application debugger. Entire API is also available as Python functions through a script bridging interface allowing development of python modules. This patch also provides a CLI wrapper to use the Tool through LLDB's command line. Highlights of the Tool and the wrapper are given below: ****************************** Intel(R) Processor Trace Tool: ****************************** - Provides execution trace of the debugged application - Uses Intel(R) Processor Trace hardware feature (already implemented inside LLDB) for this purpose -- Collects trace packets generated by this feature from LLDB, decodes and post-processes them -- Constructs the execution trace of the application -- Presents execution trace as a list of assembly instructions - Provides 4 APIs (exposed as C++ object oriented interface) -- start trace with configuration options for a thread/process, -- stop trace for a thread/process, -- get the execution flow (assembly instructions) for a thread, -- get trace specific information for a thread - Easily integrable into IDEs providing LLDB as application debugger - Entire API available as Python functions through script bridging interface -- Allows developing python apps on top of Tool - README_TOOL.txt provides more details about the Tool, its dependencies, building steps and API usage - Tool ready to use through LLDB's command line -- CLI wrapper has been developed on top of the Tool for this purpose ********************************* CLI wrapper: cli-wrapper-pt.cpp ********************************* - Provides 4 commands (syntax similar to LLDB's CLI commands): -- processor-trace start -- processor-trace stop -- processor-trace show-trace-options -- processor-trace show-instr-log - README_CLI.txt provides more details about commands and their options Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com> Reviewers: clayborg, jingham, lldb-commits, labath Reviewed By: clayborg Subscribers: ravitheja, emaste, krytarowski, mgorny Differential Revision: https://reviews.llvm.org/D33035 llvm-svn: 310261
OpenPOWER on IntegriCloud