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
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
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
*** 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 huge
effort. Alternatively, it may be worth merging all changes up to this commit,
performing the same reformatting operation locally, and then discarding the
merge for this particular commit. The commands used to accomplish this
reformatting were as follows (with current working directory as the root of
the 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 of
a meaningful prior commit. There are alternatives available that will attempt
to look through this change and find the appropriate prior commit. YMMV.
llvm-svn: 280751
The many many benefits include:
1 - Input/Output/Error streams are now handled as real streams not a push style input
2 - auto completion in python embedded interpreter
3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use
4 - it is now possible to use curses to drive LLDB (please try the "gui" command)
We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases.
llvm-svn: 200263
Execute which was never going to get run and another ExecuteRawCommandString. Took the knowledge of how
to prepare raw & parsed commands out of CommandInterpreter and put it in CommandObject where it belongs.
Also took all the cases where there were the subcommands of Multiword commands declared in the .h file for
the overall command and moved them into the .cpp file.
Made the CommandObject flags work for raw as well as parsed commands.
Made "expr" use the flags so that it requires you to be paused to run "expr".
llvm-svn: 158235
lldb_private::OptionGroup
lldb_private::OptionGroupOptions
OptionGroup lets you define a class that encapsulates settings that you want
to reuse in multiple commands. It contains only the option definitions and the
ability to set the option values, but it doesn't directly interface with the
lldb_private::Options class that is the front end to all of the CommandObject
option parsing. For that the OptionGroupOptions class can be used. It aggregates
one or more OptionGroup objects and directs the option setting to the
appropriate OptionGroup class. For an example of this, take a look at the
CommandObjectFile and how it uses its "m_option_group" object shown below
to be able to set values in both the FileOptionGroup and PlatformOptionGroup
classes. The members used in CommandObjectFile are:
OptionGroupOptions m_option_group;
FileOptionGroup m_file_options;
PlatformOptionGroup m_platform_options;
Then in the constructor for CommandObjectFile you can combine the option
settings. The code below shows a simplified version of the constructor:
CommandObjectFile::CommandObjectFile(CommandInterpreter &interpreter) :
CommandObject (...),
m_option_group (interpreter),
m_file_options (),
m_platform_options(true)
{
m_option_group.Append (&m_file_options);
m_option_group.Append (&m_platform_options);
m_option_group.Finalize();
}
We append the m_file_options and then the m_platform_options and then tell
the option group the finalize the results. This allows the m_option_group to
become the organizer of our prefs and after option parsing we end up with
valid preference settings in both the m_file_options and m_platform_options
objects. This also allows any other commands to use the FileOptionGroup and
PlatformOptionGroup classes to implement options for their commands.
Renamed:
virtual void Options::ResetOptionValues();
to:
virtual void Options::OptionParsingStarting();
And implemented a new callback named:
virtual Error Options::OptionParsingFinished();
This allows Options subclasses to verify that the options all go together
after all of the options have been specified and gives the chance for the
command object to return an error. It also gives a chance to take all of the
option values and produce or initialize objects after all options have
completed parsing.
Modfied:
virtual Error
SetOptionValue (int option_idx, const char *option_arg) = 0;
to be:
virtual Error
SetOptionValue (uint32_t option_idx, const char *option_arg) = 0;
(option_idx is now unsigned).
llvm-svn: 129415
This allows you to have a platform selected, then specify a triple using
"i386" and have the remaining triple items (vendor, os, and environment) set
automatically.
Many interpreter commands take the "--arch" option to specify an architecture
triple, so now the command options needed to be able to get to the current
platform, so the Options class now take a reference to the interpreter on
construction.
Modified the build LLVM building in the Xcode project to use the new
Xcode project level user definitions:
LLVM_BUILD_DIR - a path to the llvm build directory
LLVM_SOURCE_DIR - a path to the llvm sources for the llvm that will be used to build lldb
LLVM_CONFIGURATION - the configuration that lldb is built for (Release,
Release+Asserts, Debug, Debug+Asserts).
I also changed the LLVM build to not check if "lldb/llvm" is a symlink and
then assume it is a real llvm build directory versus the unzipped llvm.zip
package, so now you can actually have a "lldb/llvm" directory in your lldb
sources.
llvm-svn: 129112
public types and public enums. This was done to keep the SWIG stuff from
parsing all sorts of enums and types that weren't needed, and allows us to
abstract our API better.
llvm-svn: 128239
accessed by the objects that own the settings. The previous approach wasn't
very usable and made for a lot of unnecessary code just to access variables
that were already owned by the objects.
While I fixed those things, I saw that CommandObject objects should really
have a reference to their command interpreter so they can access the terminal
with if they want to output usaage. Fixed up all CommandObjects to take
an interpreter and cleaned up the API to not need the interpreter to be
passed in.
Fixed the disassemble command to output the usage if no options are passed
down and arguments are passed (all disassebmle variants take options, there
are no "args only").
llvm-svn: 114252
to specify a one-liner (either scripting or lldb command) inline.
Refactored CommandObjectBreakpointCommandAdd::Execute() a little bit and added
some comments.
Sn now, we use:
breakpoint command add -p 1 -o "conditional_break.stop_if_called_from_a()"
to specify a Python one-liner as the callback for breakpoint #1.
llvm-svn: 113672
to the debugger from GUI windows. Previously there was one global debugger
instance that could be accessed that had its own command interpreter and
current state (current target/process/thread/frame). When a GUI debugger
was attached, if it opened more than one window that each had a console
window, there were issues where the last one to setup the global debugger
object won and got control of the debugger.
To avoid this we now create instances of the lldb_private::Debugger that each
has its own state:
- target list for targets the debugger instance owns
- current process/thread/frame
- its own command interpreter
- its own input, output and error file handles to avoid conflicts
- its own input reader stack
So now clients should call:
SBDebugger::Initialize(); // (static function)
SBDebugger debugger (SBDebugger::Create());
// Use which ever file handles you wish
debugger.SetErrorFileHandle (stderr, false);
debugger.SetOutputFileHandle (stdout, false);
debugger.SetInputFileHandle (stdin, true);
// main loop
SBDebugger::Terminate(); // (static function)
SBDebugger::Initialize() and SBDebugger::Terminate() are ref counted to
ensure nothing gets destroyed too early when multiple clients might be
attached.
Cleaned up the command interpreter and the CommandObject and all subclasses
to take more appropriate arguments.
llvm-svn: 106615
Jonas Devlieghere