Update the file headers across all of the LLVM projects in the monorepoto reflect the new license.We understand that people may be surprised that we're moving the headerentirely to discuss the ne
Update the file headers across all of the LLVM projects in the monorepoto reflect the new license.We understand that people may be surprised that we're moving the headerentirely to discuss the new license. We checked this carefully with theFoundation's lawyer and we believe this is the correct approach.Essentially, all code in the project is now made available by the LLVMproject under our new license, so you will see that the license headersinclude that license only. Some of our contributors have contributedcode under our old license, and accordingly, we have retained a copy ofour old license notice in the top-level files in each project andrepository.llvm-svn: 351636
show more ...
*** 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 hugeeffort. Alternatively, it may be worth merging all changes up to this commit,performing the same reformatting operation locally, and then discarding themerge for this particular commit. The commands used to accomplish thisreformatting were as follows (with current working directory as the root ofthe 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 ofa meaningful prior commit. There are alternatives available that will attemptto look through this change and find the appropriate prior commit. YMMV.llvm-svn: 280751
Replace printf with result.Printf, so that the plugin shows its output with any configuration of the LLDB I/O streams (esp. useful in graphic environments such as Xcode)llvm-svn: 167030
Proper copyright noticellvm-svn: 166443
Implementing plugins that provide commands.This checkin adds the capability for LLDB to load plugins from external dylibs that can provide new commandsIt exports an SBCommand class from the public
Implementing plugins that provide commands.This checkin adds the capability for LLDB to load plugins from external dylibs that can provide new commandsIt exports an SBCommand class from the public API layer, and a new SBCommandPluginInterfaceThere is a minimal load-only plugin manager built into the debugger, which can be accessed via Debugger::LoadPlugin.Plugins are loaded from two locations at debugger startup (LLDB.framework/Resources/PlugIns and ~/Library/Application Support/LLDB/PlugIns) and more can be (re)loaded via the "plugin load" commandFor an example of how to make a plugin, refer to the fooplugin.cpp file in examples/plugins/commandsCaveats: Currently, the new API objects and features are not exposed via Python. The new commands can only be "parsed" (i.e. not raw) and get their command line via a char** parameter (we do not expose our internal Args object) There is no unloading feature, which can potentially lead to leaks if you overwrite the commands by reloading the same or different plugins There is no API exposed for option parsing, which means you may need to use getopt or roll-your-ownllvm-svn: 164865