This change is very mechanical. All it does is change the
signature of `Options::GetDefinitions()` and `OptionGroup::
GetDefinitions()` to return an `ArrayRef<OptionDefinition>`
instead of a `const OptionDefinition *`. In the case of the
former, it deletes the sentinel entry from every table, and
in the case of the latter, it removes the `GetNumDefinitions()`
method from the interface. These are no longer necessary as
`ArrayRef` carries its own length.
In the former case, iteration was done by using a sentinel
entry, so there was no knowledge of length. Because of this
the individual option tables were allowed to be defined below
the corresponding class (after all, only a pointer was needed).
Now, however, the length must be known at compile time to
construct the `ArrayRef`, and as a result it is necessary to
move every option table before its corresponding class. This
results in this CL looking very big, but in terms of substance
there is not much here.
Differential revision: https://reviews.llvm.org/D24834
llvm-svn: 282188
This change introduces optional marking of the column within a source
line where a thread is stopped. This marking will show up when the
source code for a thread stop is displayed, when the debug info
knows the column information, and if the optional column marking is
enabled.
There are two separate methods for handling the marking of the stop
column:
* via ANSI terminal codes, which are added inline to the source line
display. The default ANSI mark-up is to underline the column.
* via a pure text-based caret that is added in the appropriate column
in a newly-inserted blank line underneath the source line in
question.
There are some new options that control how this all works.
* settings set stop-show-column
This takes one of 4 values:
* ansi-or-caret: use the ANSI terminal code mechanism if LLDB
is running with color enabled; if not, use the caret-based,
pure text method (see the "caret" mode below).
* ansi: only use the ANSI terminal code mechanism to highlight
the stop line. If LLDB is running with color disabled, no
stop column marking will occur.
* caret: only use the pure text caret method, which introduces
a newly-inserted line underneath the current line, where
the only character in the new line is a caret that highlights
the stop column in question.
* none: no stop column marking will be attempted.
* settings set stop-show-column-ansi-prefix
This is a text format that indicates the ANSI formatting
code to insert into the stream immediately preceding the
column where the stop column character will be marked up.
It defaults to ${ansi.underline}; however, it can contain
any valid LLDB format codes, e.g.
${ansi.fg.red}${ansi.bold}${ansi.underline}
* settings set stop-show-column-ansi-suffix
This is the text format that specifies the ANSI terminal
codes to end the markup that was started with the prefix
described above. It defaults to: ${ansi.normal}. This
should be sufficient for the common cases.
Significant leg-work was done by Adrian Prantl. (Thanks, Adrian!)
differential review: https://reviews.llvm.org/D20835
reviewers: clayborg, jingham
llvm-svn: 282105
This updates getters and setters to use StringRef instead of
const char *. I tested the build on Linux, Windows, and OSX
and saw no build or test failures. I cannot test any BSD
or Android variants, however I expect the required changes
to be minimal or non-existant.
llvm-svn: 282079
Serialize breakpoint names & the hardware_requested attributes.
Also added a few missing affordances to SBBreakpoint whose absence
writing the tests pointed out.
<rdar://problem/12611863>
llvm-svn: 282036
This patch also marks the const char* versions as =delete to prevent
their use. This has the potential to cause build breakages on some
platforms which I can't compile. I have tested on Windows, Linux,
and OSX. Best practices for fixing broken callsites are outlined in
Args.h in a comment above the deleted function declarations.
Eventually we can remove these =delete declarations, but for now they
are important to make sure that all implicit conversions from
const char * are manually audited to make sure that they do not invoke a
conversion from nullptr.
llvm-svn: 281919
Where possible, remove the const char* version. To keep the
risk and impact here minimal, I've only done the simplest
functions.
In the process, I found a few opportunities for adding some
unit tests, so I added those as well.
Tested on Windows, Linux, and OSX.
llvm-svn: 281799
Moved the guts of the code from CommandObjectBreakpoint to Target (should
have done it that way in the first place.) Added an SBBreakpointList class
so there's a way to specify which breakpoints to serialize and to report the
deserialized breakpoints.
<rdar://problem/12611863>
llvm-svn: 281520
Plumb unique_ptrs<> all the way through the baton interface.
NFC, this is a minor improvement to remove the possibility of an
accidental pointer ownership issue.
Reviewed By: jingham
Differential Revision: https://reviews.llvm.org/D24495
llvm-svn: 281360
Still to come:
1) SB API's
2) Testcases
3) Loose ends:
a) serialize Thread options
b) serialize Exception resolvers
4) "break list --file" should list breakpoints contained in a file and
"break read -f 1 3 5" should then read in only those breakpoints.
<rdar://problem/12611863>
llvm-svn: 281273
mode in lldb works. I've been discussing this with Jim Ingham,
Greg Clayton, and Kate Stone for the past week or two.
Previously lldb would print three source lines (centered on the
line table entry line for the current line) followed by the assembly.
It would print the context information (module`function + offset)
before those three lines of source.
Now lldb will print up to two lines before/after the line table
entry. It prints two '*' characters for the line table line to
make it clear what line is showing assembly. There is one line of
whitespace before/after the source lines so the separation between
source & assembly is clearer. I don't print the context line
(module`function + offset). I stop printing context lines if it's
a different line table entry, or if it's a source line I've already
printed as context to another source line. If I have two line table
entries one after another for the same source line (I get these often
with clang - with different column information in them), I only print
the source line once.
I'm also using the target.process.thread.step-avoid-regexp setting
(which keeps you from stepping into STL functions that have been inlined
into your own code) and avoid printing any source lines from functions
that match that regexp.
When lldb disassembles into a new function, it will try to find the
declaration line # for the function and print all of the source lines
between the decl and the first line table entry (usually a { curly brace)
so we have a good chance of including the arguments, at least with the
debug info emitted by clang.
Finally, the # of source lines of context to show has been separated
from whether we're doing mixed source & assembly or not. Previously
specifying 0 lines of context would turn off mixed source & assembly.
I think there's room for improvement, and maybe some bugs I haven't
found yet, but it's in good enough shape to upstream and iterate at
this point.
I'm not sure how best to indicate which source line is the actual line
table # versus context lines. I'm using '**' right now. Both Kate
and Greg had the initial idea to reuse '->' (normally used to indicate
"currently executing source line") - I tried it but I wasn't thrilled,
I'm too used to the established meaning of ->.
Greg had the interesting idea of avoiding context source lines only
in two line table entries in the same source file. So we'd print
two lines before & after a source line, and then the next line table
entry (if it was on the next source line after those two context lines)
we'd display only the following two lines -- the previous two had just
been printed. If an inline source line was printed between these two,
though, we'd print the context lines for both of them. It's an
interesting idea, and I want to see how it works with both -O0 and -O3
codegen where we have different amounts of inlining.
<rdar://problem/27961419>
llvm-svn: 280906
*** 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
MSVC emits an error when one uses a const variable in a lambda without
capturing it.
gcc and clang don't emit an error in this scenario.
llvm-svn: 280707
When a process stops due to a crash, we get the crashing instruction and the
crashing memory location (if there is one). From the user's perspective it is
often unclear what the reason for the crash is in a symbolic sense.
To address this, I have added new fuctionality to StackFrame to parse the
disassembly and reconstruct the sequence of dereferneces and offsets that were
applied to a known variable (or fuction retrn value) to obtain the invalid
pointer.
This makes use of enhancements in the disassembler, as well as new information
provided by the DWARF expression infrastructure, and is exposed through a
"frame diagnose" command. It is also used to provide symbolic information, when
available, in the event of a crash.
The algorithm is very rudimentary, and it needs a bunch of work, including
- better parsing for assembly, preferably with help from LLVM
- support for non-Apple platforms
- cleanup of the algorithm core, preferably to make it all work in terms of
Operands instead of register/offset pairs
- improvement of the GetExpressioPath() logic to make prettier expression
paths, and
- better handling of vtables.
I welcome all suggestios, improvements, and testcases.
llvm-svn: 280692
easier to scan a set of options with a relatively large number of positional
arguments. This commit standardizes their formatting throughout LLDB and
applies surrounding directives to exempt them from being formatted by
clang-format.
These kinds of exemptions should be rare cases that benefit significantly
from alternative formatting. They also imply a long-term obligation to
maintain their format since the automated tools will not do so.
llvm-svn: 279882
Options used to store a reference to the CommandInterpreter instance
in the base Options class. This made it impossible to parse options
independent of a CommandInterpreter.
This change removes the reference from the base class. Instead, it
modifies the options-parsing-related methods to take an
ExecutionContext pointer, which the options may inspect if they need
to do so.
Closes https://reviews.llvm.org/D23416
Reviewers: clayborg, jingham
llvm-svn: 278440
It's always hard to remember when to include this file, and
when you do include it it's hard to remember what preprocessor
check it needs to be behind, and then you further have to remember
whether it's windows.h or win32.h which you need to include.
This patch changes the name to PosixApi.h, which is more appropriately
named, and makes it independent of any preprocessor setting.
There's still the issue of people not knowing when to include this,
because there's not a well-defined set of things it exposes other
than "whatever is missing on Windows", but at least this should
make it less painful to fix when problems arise.
This patch depends on LLVM revision r278170.
llvm-svn: 278177
review it for consistency, accuracy, and clarity. These changes attempt to
address all of the above while keeping the text relatively terse.
<rdar://problem/24868841>
llvm-svn: 275485
We had support that assumed that thread local data for a variable could be determined solely from the module in which the variable exists. While this work for linux, it doesn't work for Apple OSs. The DWARF for thread local variables consists of location opcodes that do something like:
DW_OP_const8u (x)
DW_OP_form_tls_address
or
DW_OP_const8u (x)
DW_OP_GNU_push_tls_address
The "x" is allowed to be anything that is needed to determine the location of the variable. For Linux "x" is the offset within the TLS data for a given executable (ModuleSP in LLDB). For Apple OS variants, it is the file address of the data structure that contains a pthread key that can be used with pthread_getspecific() and the offset needed.
This fix passes the "x" along to the thread:
virtual lldb::addr_t
lldb_private::Thread::GetThreadLocalData(const lldb::ModuleSP module, lldb::addr_t tls_file_addr);
Then this is passed along to the DynamicLoader::GetThreadLocalData():
virtual lldb::addr_t
lldb_private::DynamicLoader::GetThreadLocalData(const lldb::ModuleSP module, const lldb::ThreadSP thread, lldb::addr_t tls_file_addr);
This allows each DynamicLoader plug-in do the right thing for the current OS.
The DynamicLoaderMacOSXDYLD was modified to be able to grab the pthread key from the data structure that is in memory and call "void *pthread_getspecific(pthread_key_t key)" to get the value of the thread local storage and it caches it per thread since it never changes.
I had to update the test case to access the thread local data before trying to print it as on Apple OS variants, thread locals are not available unless they have been accessed at least one by the current thread.
I also added a new lldb::ValueType named "eValueTypeVariableThreadLocal" so that we can ask SBValue objects for their ValueType and be able to tell when we have a thread local variable.
<rdar://problem/23308080>
llvm-svn: 274366
For code like:
int g_global = 234;
int g_static = 345;
int main(int argc, char **argv)
{
int a = 22333;
static int g_int = 123;
return g_global + g_static + g_int + a;
}
If we stop at the "return" statement, we expect to see "argc", "argv", "a" and "g_int" when we type "frame variable" since "g_int" is a locally defined static variable, but we don't expect to see "g_global" or "g_static" unless we add the -g option to "frame variable".
llvm-svn: 272348
In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly.
llvm-svn: 272276
This is a pretty straightforward first pass over removing a number of uses of
Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there
are interfaces which take Mutex::Locker & to lock internal locks. This patch
cleans up most of the easy cases. The only non-trivial change is in
CommandObjectTarget.cpp where a Mutex::Locker was split into two.
llvm-svn: 269877
This allows expressions such as 'i == 1 || i == 2` to be executed using the IR interpreter, instead of relying on JIT code injection (which may not be available on some platforms).
Patch by cameron314
Differential Revision: http://reviews.llvm.org/D19124
llvm-svn: 269340
Summary:
The "file" variable in a LineEntry was mapped using target.source-map, except when stepping through inlined code. This patch adds a new variable to LineEntry, "original_file", that contains the original file from the debug info. "file" will continue to (possibly) be mapped.
Some code has been changed to use "original_file". This is code dealing with symbols. Code dealing with source files will still use "file". Reviewers, please confirm that these particular changes are correct.
Tests run on Ubuntu 12.04 show no regression.
Reviewers: clayborg, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D20135
llvm-svn: 269250
This is not the right thing for all clients (notably the expression parser), so put it in type lookup specific code
Fixes rdar://problem/22422313
llvm-svn: 269095
IOHandlerLinesUpdated() does nothing, and IOHandlerIsInputComplete should be
implemented but isn't. This means that multiline expressions don't work. This
patch fixes that. Test case to follow in the next commit.
llvm-svn: 268970
within a source file.
This isn't done, I need to make the name match smarter (right now it requires an
exact match which is annoying for methods of a class in a namespace.
Also, though we use it in tests all over the place, it doesn't look like we have
a test for Source Regexp breakpoints by themselves, I'll add that in a follow-on patch.
llvm-svn: 267834
This option evaluates an expression and, if the result is of pointer type, treats it as if it was an array of that many elements and displays such elements
This has a couple subtle points but is mostly as straightforward as it sounds
Add a parray N <expr> alias for this new mode
Also, extend the --object-description mode to do the moral equivalent of the above but display each element in --object-description mode
Add a poarray N <expr> alias for this
llvm-svn: 267372
Summary: Flag updated in D233237
Reviewers: spyffe, jingham, Eugene.Zelenko
Subscribers: lldb-commits, sas
Differential Revision: http://reviews.llvm.org/D18660
Change by Francis Ricci <fjricci@fb.com>
llvm-svn: 265421
quietly apply fixits for those who really trust clang's fixits.
Also, moved the retry into ClangUserExpression::Evaluate, where I can make a whole new ClangUserExpression
to do the work. Reusing any of the parts of a UserExpression in situ isn't supported at present.
<rdar://problem/25351938>
llvm-svn: 264793
Top-level Clang expressions are expressions that act as new translation units,
and define their own symbols. They do not have function wrappers like regular
expressions do, and declarations are persistent regardless of use of the dollar
sign in identifiers. Names defined by these are given priority over all other
symbol lookups.
This patch adds a new expression option, '-p' or '--top-level,' which controls
whether the expression is treated this way. It also adds a flag controlling
this to SBExpressionOptions so that this API is usable externally. It also adds
a test that validates that this works. (The test requires a fix to the Clang
AST importer which I will be committing shortly.)
<rdar://problem/22864976>
llvm-svn: 264662
This feature is controlled by an expression command option, a target property and the
SBExpressionOptions setting. FixIt's are only applied to UserExpressions, not UtilityFunctions,
those you have to get right when you make them.
This is just a first stage. At present the fixits are applied silently. The next step
is to tell the user about the applied fixit.
<rdar://problem/25351938>
llvm-svn: 264379
It would be fun to make it provide suggestions (e.g. 'can't find NString, did you mean NSString instead?'), but this worries me a little bit on the account of just how thorough of a type system scan it would have to do
llvm-svn: 264343
This solves issues such as 'apropos foo' returning valid matches just because syntax examples happen to use 'foo' as a placeholder token
Fixes rdar://9043025
llvm-svn: 264123
Win32 API calls that are Unicode aware require wide character
strings, but LLDB uses UTF8 everywhere. This patch does conversions
wherever necessary when passing strings into and out of Win32 API
calls.
Patch by Cameron
Differential Revision: http://reviews.llvm.org/D17107
Reviewed By: zturner, amccarth
llvm-svn: 264074
Persistent decls have traditionally only been types. However, we want to
be able to persist more things, like functions and global variables. This
changes some of the nomenclature and the lookup rules to make this possible.
<rdar://problem/22864976>
llvm-svn: 263864
Summary:
The gdb-remote async thread cannot modify thread state while the main thread
holds a lock on the state. Don't use locking thread iteration for bt all.
Specifically, the deadlock manifests when lldb attempts to JIT code to
symbolicate objective c while backtracing. As part of this code path,
SetPrivateState() is called on an async thread. This async thread will
block waiting for the thread_list lock held by the main thread in
CommandObjectIterateOverThreads. The main thread will also block on the
async thread during DoResume (although with a timeout), leading to a
deadlock. Due to the timeout, the deadlock is not immediately apparent,
but the inferior will be left in an invalid state after the bt all completes,
and objective-c symbols will not be successfully resolved in the backtrace.
Reviewers: andrew.w.kaylor, jingham, clayborg
Subscribers: sas, lldb-commits
Differential Revision: http://reviews.llvm.org/D18075
Change by Francis Ricci <fjricci@fb.com>
llvm-svn: 263735
This cleans things up such CommandAlias essentially can work as its own object; the aliases still live in a separate map, but are now just full-fledged CommandObjectSPs
This patch also cleans up help generation for aliases, allows aliases to vend their own help, and adds a tweak such that "dash-dash aliases", such as po, don't show the list of options for their underlying command, since those can't be provided anyway
I plan to fix up a few more things here, and then add a test case and proclaim victory
llvm-svn: 263499
Turns out that most of the code that runs expressions (e.g. the ObjC runtime grubber) on
behalf of the expression parser was using the currently selected thread. But sometimes,
e.g. when we are evaluating breakpoint conditions/commands, we don't select the thread
we're running on, we instead set the context for the interpreter, and explicitly pass
that to other callers. That wasn't getting communicated to these utility expressions, so
they would run on some other thread instead, and that could cause a variety of subtle and
hard to reproduce problems.
I also went through the commands and cleaned up the use of GetSelectedThread. All those
uses should have been trying the thread in the m_exe_ctx belonging to the command object
first. It would actually have been pretty hard to get misbehavior in these cases, but for
correctness sake it is good to make this usage consistent.
<rdar://problem/24978569>
llvm-svn: 263326
That way you can set offset breakpoints that will move as the function they are
contained in moves (which address breakpoints can't do...)
I don't align the new address to instruction boundaries yet, so you have to get
this right yourself for now.
<rdar://problem/13365575>
llvm-svn: 263049
The next step is to actually turn CommandAlias into a full-blown CommandObject citizen.
This is tricky given the current architecture of the CommandInterpreter but I think I have found a reasonable path forward.
The current plan is to make class CommandAlias : public CommandObject, and have all the several GetCommand calls not actually traverse through the alias to the underlying command object
The only times that an alias will be traversed are:
a) execution; when time comes to run an alias, I will just grab the underlying command and options, and make the interpreter execute that according to its current algorithm
b) subcommand traversal; if one has an alias to a multiword command, grabbing a subcommand will see through to the subcommand
Other operations, e.g. command listing, command names, command helps, ..., will all use the alias directly. This will, in turn, lead to the removal of the separate alias dictionary, and just mix user commands and aliases in one map
llvm-svn: 262986
- move alias help generation to CommandAlias, out of CommandInterpreter
- make alias creation use argument strings instead of OptionArgVectorSP; the former is a more reasonable currency than the latter
- remove m_is_alias from CommandObject, it wasn't actually being used
llvm-svn: 262912
Right now, obviously, this is just the pair of (CommandObjectSP,OptionArgVectorSP), so NFC
This is step one of a larger - and tricky - refactoring which will turn command aliases into interesting objects instead of passive storage that the command interpreter does smart things to
This refactoring, in turn, will allow us to do interesting things with aliases, such as intelligent and customizable help
llvm-svn: 262900
This is useful in cases such as, e.g.
(lldb) help NSString
(the user meant type lookup)
or
(lldb) help kill
(the user is looking for process kill)
Fixes rdar://24868537
llvm-svn: 262271
to allow you to step through a complex calling sequence into a particular function that may span multiple lines. Also some
test cases for this and the --step-target feature.
llvm-svn: 261953
the xcode project file to catch switch statements that have a
case that falls through unintentionally.
Define LLVM_FALLTHROUGH to indicate instances where a case has code
and intends to fall through. This should be in llvm/Support/Compiler.h;
Peter Collingbourne originally checked in there (r237766), then
reverted (r237941) because he didn't have time to mark up all the
'case' statements that were intended to fall through. I put together
a patch to get this back in llvm http://reviews.llvm.org/D17063 but
it hasn't been approved in the past week. I added a new
lldb-private-defines.h to hold the definition for now.
Every place in lldb where there is a comment that the fall-through
is intentional, I added LLVM_FALLTHROUGH to silence the warning.
I haven't tried to identify whether the fallthrough is a bug or
not in the other places.
I haven't tried to add this to the cmake option build flags.
This warning will only work for clang.
This build cleanly (with some new warnings) on macosx with clang
under xcodebuild, but if this causes problems for people on other
configurations, I'll back it out.
llvm-svn: 260930
short option as an aid to memory. Like it's w because of the W in throW.
That helps me remember. If we are going to take these out we should take them
all out. But I kind of like them.
llvm-svn: 260452
llvm::DenseSet<lldb_private::SymbolFile *> &searched_symbol_files
Each time a SymbolFile::FindTypes() is called, it needs to check the searched_symbol_files list to make sure it hasn't already been asked to find the type and return immediately if it has been checked. This will stop circular dependencies from also crashing LLDB during type queries.
This has proven to be an issue when debugging large applications on MacOSX that use DWARF in .o files.
<rdar://problem/24581488>
llvm-svn: 260434
case where you have:
1 -> foo (bar(),
2 baz(),
3 lala());
4
You are sitting on line 1, and want to step into foo, but not bar, baz & lala. Unfortunately
there are line table entries for lines 1-3, and lldb doesn't know anything about the nesting
of statement in these lines. So we'll have to use the user's intelligence... This patch adds:
(lldb) thread step-in -t foo --end-line 4
That tells lldb to keep stepping in till line 4, but stop if you step into foo. I think I would
remember to use this when faced with some of the long gnarly call sequences in lldb. But there
might be ways I haven't thought of to make it more convenient. Jason suggests having "end" as a
special token for --end-line which just means keep going to the end of the function, I really want
to get into this thing...
There should be an SB API and tests, which will come if this seems useful.
llvm-svn: 260352
This is a rather unhelpful warning indicating that the ternary operator return
types are mismatched, returning an integer and an enumeral type. Since the
integeral type is shorter to type, cast the enumeral type to `int`. Silences
the -Wextra warning from GCC.
llvm-svn: 258548
Summary:
Similar to rL256704 and rL256707, fix a few text files which were
accidentally checked in with DOS line endings, or mixed line endings.
Reviewers: jingham, emaste
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D16027
llvm-svn: 257361
Batch mode is supposed to stop execution and return control to the user when an
exceptional stop occurs (crash, signal or instrumentation). But attach always stops
with a SIGSTOP on OSX (maybe on Linux too?) which would short circuit the rest of the
commands given.
This change allows a command result object to indicate that it expected to leave the
process stopped with an exceptional stop reason, and it is okay for batch mode to keep going.
<rdar://problem/22243143>
llvm-svn: 257120
This patch adds support the command 'source info' as follows:
(lldb) help source info
Display source line information (as specified) based on the current executable's
debug info.
Syntax: source info <cmd-options>
Command Options Usage:
source info [-c <count>] [-s <shlib-name>] [-f <filename>] [-l <linenum>] [-e <linenum>]
source info [-c <count>] [-s <shlib-name>] [-n <symbol>]
source info [-c <count>] [-a <address-expression>]
-a <address-expression> ( --address <address-expression> )
Lookup the address and display the source information for the corresponding
file and line.
-c <count> ( --count <count> )
The number of line entries to display.
-e <linenum> ( --end-line <linenum> )
The line number at which to stop displaying lines.
-f <filename> ( --file <filename> )
The file from which to display source.
-l <linenum> ( --line <linenum> )
The line number at which to start the displaying lines.
-n <symbol> ( --name <symbol> )
The name of a function whose source to display.
-s <shlib-name> ( --shlib <shlib-name> )
Look up the source in the given module or shared library (can be specified
more than once).
For example:
(lldb) source info --file x.h
Lines for file x.h in compilation unit x.cpp in `x
[0x0000000100000d00-0x0000000100000d10): /Users/dawn/tmp/./x.h:10
[0x0000000100000d10-0x0000000100000d1b): /Users/dawn/tmp/./x.h:10
The new options are used to fix the MI command:
-symbol-list-lines <file>
which didn't work for header files because it called:
target modules dump line-table <file>
which only dumps line tables for a compilation unit.
The patch also fixes a bug in the error reporting when no files were supplied to the command. Previously you'd get:
(lldb) target modules dump line-table
error:
Syntax:
error: no source filenames matched any command arguments
Now you get:
error: file option must be specified.
Reviewed by: clayborg, jingham, ki.stfu
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D15593
llvm-svn: 256863
find the largest address range (possibly combining multiple
LineEntry's for this line number) that is contiguous.
This allows lldb's fast-step stepping algorithm to potentially
run for a longer address range than if we have to stop at every
LineEntry indicating a subexpression in the source line.
http://reviews.llvm.org/D15407
<rdar://problem/23270882>
llvm-svn: 255590
The standard remote debugging workflow with gdb is to start the
application on the remote host under gdbserver (e.g.: gdbserver :5039
a.out) and then connect to it with gdb.
The same workflow is supported by debugserver/lldb-gdbserver with a very
similar syntax but to access all features of lldb we need to be
connected also to an lldb-platform instance running on the target.
Before this change this had to be done manually with starting a separate
lldb-platform on the target machine and then connecting to it with lldb
before connecting to the process.
This change modifies the behavior of "platform connect" with
automatically connecting to the process instance if it was started by
the remote platform. With this command replacing gdbserver in a gdb
based worflow is usually as simple as replacing the command to execute
gdbserver with executing lldb-platform.
Differential revision: http://reviews.llvm.org/D14952
llvm-svn: 255016
This change introduce 3 different working mode for Platform::LoadImage
depending on the file specs specified.
* If only a remote file is specified then the remote file is loaded on
the target (same behavior as before)
* If only a local file is specified then the local file is installed to
the current working directory and then loaded from there.
* If both local and remote file is specified then the local file is
installed to the specified location and then loaded from there.
The same options are exposed on the SB API with a new method LoadImage
method while the old signature presers its meaning.
On the command line the installation of the shared library can be specified
with the "--install" option of "process load".
Differential revision: http://reviews.llvm.org/D15152
llvm-svn: 255014
On android the symbols exposed by libdl (dlopen, dlclose, dlerror)
prefixed by "__dl_". This change moves the handling of process
load/unload to the platform object and override it for android to
handle the special prefix.
Differential revision: http://reviews.llvm.org/D11465
llvm-svn: 254504
Revert "Remove a few vestigial typedefs from the old world"
This reverts commit 05872cda2a00fbd988c4fc761b1f87fe9edce224.
Revert "Cleanup the type X list commands to use the new ForEach goodness"
This reverts commit 85b1d83819a22cdc9ef12f58fd4fa92b473a4f81.
llvm-svn: 253455
breakpoint as "file address" so that the address breakpoint will track that
module even if it gets loaded in a different place. Also fixed the Address
breakpoint resolver so that it handles this tracking correctly.
llvm-svn: 253308
This is a first pass at a cleanup of that code, modernizing the "type X clear" commands, and providing the basic infrastructure I plan to use all over
More cleanup will come over the next few days
llvm-svn: 253125
instance:
break set -l c++ -r Name
will only break on C++ symbols that match Name, not ObjC or plain C symbols. This also works
for "break set -n" and there are SB API's to pass this as well.
llvm-svn: 252356
This is slightly harder to test because formatters cannot be added to language categories, so deletions are irreversible (in a debugger run)
I plan to add a test case soon, but I need to think about the right approach to obtain one
llvm-svn: 251660
"expr -r" does this. It also returns to a REPL if the LLDB command interpreter
is neseted inside it, for example in cases where a REPL command resulted in a
breakpoint being hit or a crash.
llvm-svn: 250780
There were a number of const qualifiers being cast away which caused warnings.
This cluttered the output hiding real errors. Silence them by explicit casting.
NFC.
llvm-svn: 250662
Previous commit r250281 broke TestDataFormatterSmartArray.py
Resolved in in this patch by adding the new enum eFormatVectorOfFloat16 to FormatManager.
Differential Revision: http://reviews.llvm.org/D13730
llvm-svn: 250499
* ArchSpec::MergeFrom() would erroneously promote an unspecified
unknown to a specified unknown when both the ArchSpec and the merged
in ArchSpec were both unspecified unknowns. This no longer happens,
which fixes issues with global module cache lookup in some
situations.
* Added ArchSpec::DumpTriple(Stream&) that now properly prints
unspecified unknowns as '*' and specified unknows as 'unknown'.
This makes it trivial to tell the difference between the two.
Converted printing code over ot using DumpTriple() rather than
building from scratch.
* Fixed up a couple places that were not guaranteeing that an
unspecified unknown was recorded as such.
llvm-svn: 250253
When the target settings are consulted to decide the expression language
is decided in CommandObjectExpression, this doesn't help if you're running
SBFrame::EvaluateExpression(). Moving the logic into UserExpression fixes
this.
Based on patch from scallanan@apple.com
Reviewed by: dawn
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13267
llvm-svn: 249624
Summary:
This removes all uses of virtual on functions
where override could be used, including on destructors.
It also adds override where virtual was previously
missing.
Reviewers: clayborg, labath
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13503
llvm-svn: 249564
Currently, it only supports Objective-C - C++ types can be looked up through debug info via 'image lookup -t', whereas ObjC types via this command are looked up by runtime introspection
This behavior is in line with type lookup's behavior in Xcode 7, but I am definitely open to feedback as to what makes the most sense here
llvm-svn: 249047
Also added some target-level search functions so that persistent variables and
symbols can be searched for without hand-iterating across the map of
TypeSystems.
llvm-svn: 249027
This is meant to support languages that have a scripting mode with top-level code that acts as global
For now, this flag only controls whether 'frame variable' will attempt to treat globals as locals when within such a function
llvm-svn: 248960
the corresponding TypeSystem. This makes sense because what kind of data there
is -- and how it can be looked up -- depends on the language.
Functionality that is common to all type systems is factored out into
PersistentExpressionState.
llvm-svn: 248934
.ARM.exidx/.ARM.extab sections contain unwind information used on ARM
architecture from unwinding from an exception.
Differential revision: http://reviews.llvm.org/D13245
llvm-svn: 248903
There are still a bunch of dependencies on the plug-in, but this helps to
identify them.
There are also a few more bits we need to move (and abstract, for example the
ClangPersistentVariables).
llvm-svn: 248612
Summary:
In bug 24074, the type information is not shown
correctly. This commit includes the following -
-> Changes for displaying correct type based on
current lexical scope for the command "image
lookup -t"
-> The corresponding testcase.
Reviewers: jingham, ovyalov, spyffe, richard.mitton, clayborg
Differential Revision: http://reviews.llvm.org/D12404
llvm-svn: 248366
Summary:
This is no longer related to Clang and is just an opaque pointer
to data for a compiler type.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D13039
llvm-svn: 248288
This cleans up type systems to be more pluggable. Prior to this we had issues:
- Module, SymbolFile, and many others has "ClangASTContext &GetClangASTContext()" functions. All have been switched over to use "TypeSystem *GetTypeSystemForLanguage()"
- Cleaned up any places that were using the GetClangASTContext() functions to use TypeSystem
- Cleaned up Module so that it no longer has dedicated type system member variables:
lldb::ClangASTContextUP m_ast; ///< The Clang AST context for this module.
lldb::GoASTContextUP m_go_ast; ///< The Go AST context for this module.
Now we have a type system map:
typedef std::map<lldb::LanguageType, lldb::TypeSystemSP> TypeSystemMap;
TypeSystemMap m_type_system_map; ///< A map of any type systems associated with this module
- Many places in code were using ClangASTContext static functions to place with CompilerType objects and add modifiers (const, volatile, restrict) and to make typedefs, L and R value references and more. These have been made into CompilerType functions that are abstract:
class CompilerType
{
...
//----------------------------------------------------------------------
// Return a new CompilerType that is a L value reference to this type if
// this type is valid and the type system supports L value references,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
GetLValueReferenceType () const;
//----------------------------------------------------------------------
// Return a new CompilerType that is a R value reference to this type if
// this type is valid and the type system supports R value references,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
GetRValueReferenceType () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a const modifier to this type if
// this type is valid and the type system supports const modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddConstModifier () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a volatile modifier to this type if
// this type is valid and the type system supports volatile modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddVolatileModifier () const;
//----------------------------------------------------------------------
// Return a new CompilerType adds a restrict modifier to this type if
// this type is valid and the type system supports restrict modifiers,
// else return an invalid type.
//----------------------------------------------------------------------
CompilerType
AddRestrictModifier () const;
//----------------------------------------------------------------------
// Create a typedef to this type using "name" as the name of the typedef
// this type is valid and the type system supports typedefs, else return
// an invalid type.
//----------------------------------------------------------------------
CompilerType
CreateTypedef (const char *name, const CompilerDeclContext &decl_ctx) const;
};
Other changes include:
- Removed "CompilerType TypeSystem::GetIntTypeFromBitSize(...)" and CompilerType TypeSystem::GetFloatTypeFromBitSize(...) and replaced it with "CompilerType TypeSystem::GetBuiltinTypeForEncodingAndBitSize(lldb::Encoding encoding, size_t bit_size);"
- Fixed code in Type.h to not request the full type for a type for no good reason, just request the forward type and let the type expand as needed
llvm-svn: 247953
Before we had:
ClangFunction
ClangUtilityFunction
ClangUserExpression
and code all over in lldb that explicitly made Clang-based expressions. This patch adds an Expression
base class, and three pure virtual implementations for the Expression kinds:
FunctionCaller
UtilityFunction
UserExpression
You can request one of these expression types from the Target using the Get<ExpressionType>ForLanguage.
The Target will then consult all the registered TypeSystem plugins, and if the type system that matches
the language can make an expression of that kind, it will do so and return it.
Because all of the real expression types need to communicate with their ExpressionParser in a uniform way,
I also added a ExpressionTypeSystemHelper class that expressions generically can vend, and a ClangExpressionHelper
that encapsulates the operations that the ClangExpressionParser needs to perform on the ClangExpression types.
Then each of the Clang* expression kinds constructs the appropriate helper to do what it needs.
The patch also fixes a wart in the UtilityFunction that to use it you had to create a parallel FunctionCaller
to actually call the function made by the UtilityFunction. Now the UtilityFunction can be asked to vend a
FunctionCaller that will run its function. This cleaned up a lot of boiler plate code using UtilityFunctions.
Note, in this patch all the expression types explicitly depend on the LLVM JIT and IR, and all the common
JIT running code is in the FunctionCaller etc base classes. At some point we could also abstract that dependency
but I don't see us adding another back end in the near term, so I'll leave that exercise till it is actually necessary.
llvm-svn: 247720
ehframe_ & from gdb_ to stabs_ for clarity.
Also document the fact that i386 eh_frame on Darwin has the register
numbers swapped for ebp/esp from the DWARF register numbers so no one
copies these defines for other i386 ABI plugins. This bug only ever
existed on Darwin.
No code changes, just renaming variables.
llvm-svn: 246834
* Use the frame's context (instead of just the target's) when evaluating,
so that the language of the frame's CU can be used to select the
compiler and/or compiler options to use when parsing the expression.
This allows for modules built with mixed languages to be parsed in
the context of their frame.
* Add all C and C++ language variants when determining the language options
to set.
* Enable C++ language options when language is C or ObjC as a workaround since
the expression parser uses features of C++ to capture values.
* Enable ObjC language options when language is C++ as a workaround for ObjC
requirements.
* Disable C++11 language options when language is C++03.
* Add test TestMixedLanguages.py to check that the language being used
for evaluation is that of the frame.
* Fix test TestExprOptions.py to check for C++11 instead of C++ since C++ has
to be enabled for C, and remove redundant expr --language test for ObjC.
* Fix TestPersistentPtrUpdate.py to not require C++11 in C.
Reviewed by: clayborg, spyffe, jingham
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11102
llvm-svn: 246829
Summary:
This doesn't exist in other LLVM projects any longer and doesn't
do anything.
Reviewers: chaoren, labath
Subscribers: emaste, tberghammer, lldb-commits, danalbert
Differential Revision: http://reviews.llvm.org/D12586
llvm-svn: 246749
almost all the elements on the list can't actually be passed to the language
command and all the ones that can have already been listed in the subcommands
list.
<rdar://problem/22551082>
llvm-svn: 246740
This is still something I need to fix, but at least it's not so ugly, and it's
consistent with the other code that does that so we will catch it when we purge
all such code.
llvm-svn: 246738
Clang-specific part, create the ExpressionVariable source/header file and
move ClangExpressionVariable into the Clang expression parser plugin.
It is expected that there are some ugly #include paths... these will be resolved
by either (1) making that code use generic expression variables (once they're
separated appropriately) or (2) moving that code into a plug-in, often
the expression parser plug-in.
llvm-svn: 246737
Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files.
Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types.
Bulk renames for things that used to return a ClangASTType which is now CompilerType:
"Type::GetClangFullType()" to "Type::GetFullCompilerType()"
"Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()"
"Type::GetClangForwardType()" to "Type::GetForwardCompilerType()"
"Value::GetClangType()" to "Value::GetCompilerType()"
"Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)"
"ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()"
many more renames that are similar.
llvm-svn: 245905
This is more preparation for multiple different kinds of types from different compilers (clang, Pascal, Go, RenderScript, Swift, etc).
llvm-svn: 244689
This is the work done by Ryan Brown from http://reviews.llvm.org/D8712 that makes a TypeSystem class and abstracts types to be able to use a type system.
All tests pass on MacOSX and passed on linux the last time this was submitted.
llvm-svn: 244679
This patch adds the option -l/--language to the expression command, for
use when setting the language options or choosing an alternate FE. If
not specified, the target.language setting is used.
Reviewed by: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11447
llvm-svn: 243187
Summary:
For certain data structures, when the synthetic child provider returns
zero children, a summary like "Empty instance of <typename>" could be
more appropriate than something like "size=0 {}". This new option helps
hide the trailing "{}".
This is also exposed with a -h option for the command "type summary add".
Reviewers: granata.enrico
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D11473
llvm-svn: 243166
Target and breakpoints options were added:
breakpoint set --language lang --name func
settings set target.language pascal
These specify the Language to use when interpreting the breakpoint's
expression (note: currently only implemented for breakpoints on
identifiers). If the breakpoint language is not set, the target.language
setting is used.
This support is required by Pascal, for example, to set breakpoint at 'ns.foo'
for function 'foo' in namespace 'ns'.
Tests on the language were also added to Module::PrepareForFunctionNameLookup
for efficiency.
Reviewed by: clayborg
Subscribers: jingham, lldb-commits
Differential Revision: http://reviews.llvm.org/D11119
llvm-svn: 242844
Existing commands supplying this type of help content have been reworked to take advantage of the changes. In addition to formatting changes, content was changes for accuracy and clarity purposes.
<rdar://problem/21269977>
llvm-svn: 242122
Summary:
- Consolidate Unix signals selection in UnixSignals.
- Make Unix signals available from platform.
- Add jSignalsInfo packet to retrieve Unix signals from remote platform.
- Get a copy of the platform signal for each remote process.
- Update SB API for signals.
- Update signal utility in test suite.
Reviewers: ovyalov, clayborg
Subscribers: chaoren, jingham, labath, emaste, tberghammer, lldb-commits
Differential Revision: http://reviews.llvm.org/D11094
llvm-svn: 242101
The new command add functionality to print out domain specific
information for reporting a bug. Currently the only supported
domain is stack unwinding (with "bugreport unwind") but adding
new domains is fairly easy.
Differential revision: http://reviews.llvm.org/D10868
llvm-svn: 241252
give them a meaningful error message instead of
"Unable to find process plug-in for core file ...".
<rdar://problem/21255759>
<rdar://problem/21091522>
http://blog.ignoranthack.me/?p=204
llvm-svn: 240753
A few extras were fixed
- Symbol::GetAddress() now returns an Address object, not a reference. There were places where people were accessing the address of a symbol when the symbol's value wasn't an address symbol. On MacOSX, undefined symbols have a value zero and some places where using the symbol's address and getting an absolute address of zero (since an Address object with no section and an m_offset whose value isn't LLDB_INVALID_ADDRESS is considered an absolute address). So fixing this required some changes to make sure people were getting what they expected.
- Since some places want to access the address as a reference, I added a few new functions to symbol:
Address &Symbol::GetAddressRef();
const Address &Symbol::GetAddressRef() const;
Linux test suite passes just fine now.
<rdar://problem/21494354>
llvm-svn: 240702
* Add and fix the emulation of several instruction.
* Disable frame pointer usage on Android.
* Specify return address register for the unwind plan instead of explict
tracking the value of RA.
* Replace prologue detection heuristics (unreliable in several cases)
with a logic to follow the branch instructions and restore the CFI
value based on them. The target address for a branch should have the
same CFI as the source address (if they are in the same function).
* Handle symbols in ELF files where the symbol size is not specified
with calcualting their size based on the next symbol (already done
in MachO files).
* Fix architecture in FuncUnwinders with filling up the inforamtion
missing from the object file with the architecture of the target.
* Add code to read register wehn the value is set to "IsSame" as it
meanse the value of a register in the parent frame is the same as the
value in the current frame.
Differential revision: http://reviews.llvm.org/D10447
llvm-svn: 240533
Summary:
This should solve the issue of sending denormalized paths over gdb-remote
if we stick to GetPath(false) in GDBRemoteCommunicationClient, and let the
server handle any denormalization.
Reviewers: ovyalov, zturner, vharron, clayborg
Reviewed By: clayborg
Subscribers: tberghammer, emaste, lldb-commits
Differential Revision: http://reviews.llvm.org/D9728
llvm-svn: 238604
Since interaction with the python interpreter is moving towards
being more isolated, we won't be able to include this header from
normal files anymore, all includes of it should be localized to
the python library which will live under source/bindings/API/Python
after a future patch.
None of the files that were including this header actually depended
on it anyway, so it was just a dead include in every single instance.
llvm-svn: 238581
Summary:
There is an issue in lldb where the command prompt can appear at the wrong time. The partial fix
we have in for this is not working all the time and is introducing unnecessary delays. This
change does:
- Change Process:SyncIOHandler to use integer start id's for synchronization to avoid it being
confused by quick start-stop cycles. I picked this up from a suggested patch by Greg to
lldb-dev.
- coordinates printing of asynchronous text with the iohandlers. This is also based on a
(different) Greg's patch, but I have added stronger synchronization to it to avoid races.
Together, these changes solve the prompt problem for me on linux (both with and without libedit).
I think they should behave similarly on Mac and FreeBSD and I think they will not make matters
worse for windows.
Test Plan: Prompt comes out alright. All tests still pass on linux.
Reviewers: clayborg, emaste, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9823
llvm-svn: 238313
This works for Python commands defined via a class (implement get_flags on your class) and C++ plugin commands (which can call SBCommand::GetFlags()/SetFlags())
Flags allow features such as not letting the command run if there's no target, or if the process is not stopped, ...
Commands could always check for these things themselves, but having these accessible via flags makes custom commands more consistent with built-in ones
llvm-svn: 238286
Summary: This enables correct handling of real time signals by lldb.
Test Plan: Added a test that verifies handling of SIGRTMIN
Reviewers: tberghammer, ovyalov
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9911
llvm-svn: 238009
Summary: It should default to working-dir/src-filename if dst is not specified.
Reviewers: clayborg, flackr
Reviewed By: flackr
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D9890
llvm-svn: 237831
This patch initially was committed in r237460 but later it was reverted (r237479) due to 4 new failures:
* TestExitDuringStep.py
* TestNumThreads.py
* TestThreadExit.py
* TestThreadStates.py
This patch also fixes these tests.
llvm-svn: 237566
Summary:
This option forces to only set a source line breakpoint when there is an exact-match
This patch includes the following commits:
# Add the -m/--exact-match option in "breakpoint set" command
## Add exact_match arg in BreakpointResolverFileLine ctor
## Add m_exact_match field in BreakpointResolverFileLine
## Add exact_match arg in BreakpointResolverFileRegex ctor
## Add m_exact_match field in BreakpointResolverFileRegex
## Add exact_match arg in Target::CreateSourceRegexBreakpoint
## Add exact_match arg in Target::CreateBreakpoint
## Add -m/--exact-match option in "breakpoint set" command
# Add target.exact-match option to skip BP if source line doesn't match
## Add target.exact-match global option
## Add Target::GetExactMatch
## Refactor Target::CreateSourceRegexBreakpoint to accept LazyBool exact_match (was bool)
## Refactor Target::CreateBreakpoint to accept LazyBool exact_match (was bool)
# Add target.exact-match test in SettingsCommandTestCase
# Add BreakpointOptionsTestCase tests to test --skip-prologue/--exact-match options
# Fix a few typos in lldbutil.check_breakpoint_result func
# Rename --exact-match/m_exact_match/exact_match/GetExactMatch to --move-to-nearest-code/m_move_to_nearest_code/move_to_nearest_code/GetMoveToNearestCode
# Add exact_match field in BreakpointResolverFileLine::GetDescription and BreakpointResolverFileRegex::GetDescription, for example:
was:
```
1: file = '/Users/IliaK/p/llvm/tools/lldb/test/functionalities/breakpoint/breakpoint_command/main.c', line = 12, locations = 1, resolved = 1, hit count = 2
1.1: where = a.out`main + 20 at main.c:12, address = 0x0000000100000eb4, resolved, hit count = 2
```
now:
```
1: file = '/Users/IliaK/p/llvm/tools/lldb/test/functionalities/breakpoint/breakpoint_command/main.c', line = 12, exact_match = 0, locations = 1, resolved = 1, hit count = 2
1.1: where = a.out`main + 20 at main.c:12, address = 0x0000000100000eb4, resolved, hit count = 2
```
Test Plan:
./dotest.py -v --executable $BUILDDIR/bin/lldb functionalities/breakpoint/
./dotest.py -v --executable $BUILDDIR/bin/lldb settings/
./dotest.py -v --executable $BUILDDIR/bin/lldb tools/lldb-mi/breakpoint/
Reviewers: jingham, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits, clayborg, jingham
Differential Revision: http://reviews.llvm.org/D9273
llvm-svn: 237460
Summary:
This patch is the beginnings of support for Non-stop mode in the remote protocol. Letting a user examine stopped threads, while other threads execute freely.
Non-stop mode is enabled using the setting target.non-stop-mode, which sends a QNonStop packet when establishing the remote connection.
Changes are also made to treat the '?' stop reply packet differently in non-stop mode, according to spec https://sourceware.org/gdb/current/onlinedocs/gdb/Remote-Non_002dStop.html#Remote-Non_002dStop.
A setting for querying the remote for default thread on setup is also included.
Handling of '%' async notification packets will be added next.
Reviewers: clayborg
Subscribers: lldb-commits, ADodds, ted, deepak2427
Differential Revision: http://reviews.llvm.org/D9656
llvm-svn: 237239
Removed some unused variables, added some consts, changed some casts
to const_cast. I don't think any of these changes are very
controversial.
Differential Revision: http://reviews.llvm.org/D9674
llvm-svn: 237218
Summary: This patch moves synchronization of iohandler to CommandObjectProcessLaunch::DoExecute like it was done in CommandObjectProcessContinue::DoExecute.
Reviewers: jingham, clayborg
Reviewed By: clayborg
Subscribers: lldb-commits, clayborg, jingham
Differential Revision: http://reviews.llvm.org/D9373
llvm-svn: 236699
follow-up to the change in r235158. Right now if you attach to
a process and type "kill", lldb doesn't kill it, it detaches.
<rdar://problem/20691198>
llvm-svn: 236363
breakpoints, for instance on the class of the thrown object.
This change doesn't actually make that work, the part where we
extract the thrown object type from the throw site isn't done yet.
This provides a general programmatic "precondition" that you can add
to breakpoints to give them the ability to do filtering on the LLDB
side before we pass the stop on to the user-provided conditions &
callbacks.
llvm-svn: 235538
the changes in r233255/r233258. Normally if lldb attaches to
a running process, when we call Process::Destroy, we want to detach
from the process. If lldb launched the process itself, ::Destroy
should kill it.
However, if we attach to a process and the driver calls SBProcess::Kill()
(which calls Destroy), we need to kill it even if we didn't launch it
originally.
The force_kill param allows for the SBProcess::Kill method to force the
behavior of Destroy.
<rdar://problem/20424439>
llvm-svn: 235158
Summary:
This should always be true but sometimes is not, during platform bring
up. As recommended by Jim Ingham, an assertion should be enough here to
help.
This addresses post commit comments in http://reviews.llvm.org/D8554.
Test Plan: Run unit tests.
Reviewers: jasonmolenda, emaste, jingham, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8574
llvm-svn: 233298
Summary:
Presently, if a log file already exists, lldb simply starts overwriting bits of it, without
truncating or anything. This patch makes it use eFileOptionFileTruncate by default. It also adds
an --append option, which will append to the file without truncating. A test is included.
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D8450
llvm-svn: 232801
So that we don't have to update every single #include in the entire
codebase to #include this new header (which used to get included by
lldb-private-log.h, we automatically #include "Logging.h" from
within "Log.h".
llvm-svn: 232653
This removes ScriptInterpreterObject from the codebase completely.
Places that used to rely on ScriptInterpreterObject now use
StructuredData::Object and its derived classes. To support this,
a new type of StructuredData object is introduced, called
StructuredData::Generic, which stores a void*. Internally within
the python library, StructuredPythonObject subclasses this
StructuredData::Generic class so that it can addref and decref
the python object on construction and destruction.
Additionally, all of the classes in PythonDataObjects.h such
as PythonList, PythonDictionary, etc now provide a method to
create an instance of the corresponding StructuredData type. For
example, there is PythonDictionary::CreateStructuredDictionary.
To eliminate dependencies on PythonDataObjects for external
callers, all ScriptInterpreter methods now return only
StructuredData classes
The rest of the changes in this CL are focused on fixing up
users of PythonDataObjects classes to use the new StructuredData
classes.
llvm-svn: 232534
This works by creating a command backed by a class whose interface should - at least - include
def __init__(self, debugger, session_dict)
def __call__(self, args, return_obj, exe_ctx)
What works:
- adding a command via command script add --class
- calling a thusly created command
What is missing:
- support for custom help
- test cases
The missing parts will follow over the next couple of days
This is an improvement over the existing system as:
a) it provides an obvious location for commands to provide help strings (i.e. methods)
b) it allows commands to store state in an obvious fashion
c) it allows us to easily add features to script commands over time (option parsing and subcommands registration, I am looking at you :-)
llvm-svn: 232136
Debugger.h is a huge file that gets included everywhere, and
FormatManager.h brings in a ton of unnecessary stuff and doesn't
even use anything from it in the header.
llvm-svn: 231161
This continues the effort to reduce header footprint and improve
build speed by removing clang and other unnecessary headers
from Target.h. In one case, some headers were included solely
for the purpose of declaring a nested class in Target, which was
not needed by anybody outside the class. In this case the
definition and implementation of the nested class were isolated
in the .cpp file so the header could be removed.
llvm-svn: 231107
Summary:
Presently Args::SetCommandString allows quotes to be escaped with backslash. However, the
backslash itself is not removed from the argument, nor there is a way to escape the backslash
itself. This leads to surprising results:
"a b" c" -> 'a b', 'c' # Here we actually have an unterminated quote, but that is ignored
"a b\" c" -> 'a b\" c' # We try to escape the quote. That works but the backslash is not removed.
"a b\\" c" -> 'a b\\" c' # Escaping the backslash has no effect.
This change changes quote handling to be more shell-like:
- single quotes and backquotes are literal and there is no way to escape the closing quote or
anything else inside;
- inside double quotes you can use backslash to escape the closing quote and another backslash
- outside any quotes, you can use backslash to escape quotes, spaces and itself.
This makes the parsing more consistent with what the user is familiar and increases the
probability that pasting the command line from shell to the "process launch" command "just work".
Reviewers: clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7855
llvm-svn: 230955
Fix this by returning the fact that the "symbols" word is complete if there is nothing else to complete after the "symbols" word.
<rdar://problem/19164599>
llvm-svn: 230408
Summary:
Currently we have some settings which treat "\ " on settings set commands specially. E.g., it is
a valid way of specifying an argument of " " to a target. However, this fails if "\ " is the last
argument as CommandObjectSettingsSet strips trailing whitespace. This resulted in a surprising
argument of "\" to the target.
This patch disables the training whitespace removal at a global
level. Instead, for each argument type we locally determine whether whitespace stripping makes
sense. Currently, I strip whitespace for all simple object type except of regex and
format-string, with the rationale that these two object types do their own complex parsing and we
want to interfere with them as least as possible. Specifically, stripping the whitespace of a
regex "\ " will result in a (surprising?) error "trailing backslash". Furthermore, the default
value of dissasembly-format setting already contains a trailing space and there is no way for the
user to type this in manually if we strip whitespace.
Reviewers: clayborg, zturner
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D7592
llvm-svn: 229382
changing it was in r219544 - after living on that for a few
months, I wanted to take another crack at this.
The disassembly-format setting still exists and the old format
can be user specified with a setting like
${current-pc-arrow}${addr-file-or-load}{ <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>}:
This patch was discussed in http://reviews.llvm.org/D7578
<rdar://problem/19726421>
llvm-svn: 229186
Summary:
This patch adds -exec-arguments command for lldb-mi. -exec-arguments command allows to specify arguments for executable file in MI mode. Also it contains tests for that command.
Btw, new added files was formatted by clang-format.
Reviewers: abidh, zturner, clayborg
Reviewed By: clayborg
Subscribers: zturner, emaste, clayborg, jingham, lldb-commits
Differential Revision: http://reviews.llvm.org/D6965
llvm-svn: 229110
SBTarget::BreakpointCreateBySourceRegex that takes file spec lists to the Python interface,
and add a test for this.
<rdar://problem/19805037>
llvm-svn: 228938
A runtime support value is a ValueObject whose only purpose is to support some language runtime's operation, but it does not directly provide any user-visible benefit
As such, unless the user is working on the runtime support, it is mostly safe for them not to see such a value when debugging
It is a language runtime's job to check whether a ValueObject is a support value, and that - in conjunction with a target setting - is used by frame variable and target variable
SBFrame::GetVariables gets a new overload with yet another flag to dictate whether to return those support values to the caller - that which defaults to the setting's value
rdar://problem/15539930
llvm-svn: 228791
This also hooks up the new C++14 language constant to be treated
the same as the other C++ language constants.
Differential Revision: http://reviews.llvm.org/D7429
llvm-svn: 228386
and/or one or more addresses (with -a) and until will stop at the first one of thesepoints it hits,
or on exit from the function if you leave the function before hitting any of these stop points.
<rdar://problem/12438270>
llvm-svn: 228370
redirecting output to a path that will work well on host or target.
copying file from output location to location on local host that
test will read from
llvm-svn: 228217
number of bytes to write into the inferior process, the "default byte size" will be 1.
In that case, we want to copy the entire file into memory. The code was looking for
a default byte size of 0 to indicate that the user had not provided a specific # of
bytes to copy; adjust that to 1 to match the actual default value.
<rdar://problem/18074973>
llvm-svn: 228067
./dotest.py -A x86_64 -C clang -v -t -f TestImageListMultiArchitecture.test_image_list_shows_multiple_architectures
The problem was that if the platform wasn't compatible with the current file in the "target create" command, it wasn't finding a platform that was like it used to.
Also, the currently selected platform was being used upload the file _before_ the target was created which was incorrect as "target create a.out" might switch platforms if its architecture doesn't match, so I moved the uploading to happen after the target was created so we use the right platform (the one in the target, not the selected one).
llvm-svn: 227380
This is necessary because the byte size of an ObjC class type is not reliably statically knowable (e.g. because superclasses sit deep in frameworks that we have no debug info for)
The lack of reliable size info is a problem when trying to freeze-dry an ObjC instance (not the pointer, the pointee)
This commit lays the foundation for having language runtimes help in figuring out byte sizes, and having ClangASTType ask for runtime help
No feature change as no runtime actually implements the logic, and nowhere is an ExecutionContext passed in yet
llvm-svn: 227274
Make sure the selected platform is always used
Make sure that the host uses the connect://hostname to connect to both
the lldb-platform and the lldb-gdbserver rather than what the platform
reports as the hostname of the lldb-gdbserver
Make sure that lldb-platform uses the IP address on it's connection
back to the host instead of the hostname that the host sends to it
when launching lldb-gdbserver with the remote host information
Tested on OSX and Linux
llvm-svn: 226712
The refactor was motivated by some comments that Greg made
http://reviews.llvm.org/D6918
and also to break a dependency cascade that caused functions linking
in string->int conversion functions to pull in most of lldb
llvm-svn: 226199
This is done by adding a "Variable *" to SymbolContext and allowing SymbolFile::ResolveSymbolContext() so if an address is resolved into a symbol context, we can include the global or static variable for that address.
This means you can now find global variables that are merged globals when doing a "image lookup --verbose --address 0x1230000". Previously we would resolve a symbol and show "_MergedGlobals123 + 1234". But now we can show the global variable name.
The eSymbolContextEverything purposely does not include the new eSymbolContextVariable in its lookup since stack frame code does many lookups and we don't want it triggering the global variable lookups.
<rdar://problem/18945678>
llvm-svn: 226084
The default help display now shows the alias collection by default, and hides commands whose named begin with an underscore. Help is primarily useful to those unfamiliar with LLDB and should aim to answer typical questions while still being able to provide more esoteric answers when required. To that latter end an argument to include the hidden commands in help has been added, and instead of having a help flag to show aliases there is now one to hide them. This final change might be controversial as it repurposes the -a shorthand as the opposite of its original meaning.
The previous implementation of OutputFormattedHelpText was easily confused by embedded newlines. The new algorithm correctly breaks on the FIRST newline or LAST space/tab before the target column count rather than treating all whitespace interchangeably.
Command interpreters now have the ability to specify help prologue text and a command prefix string. Neither are used in the current LLDB sources but are required to support REPL-like extensions where LLDB commands must be prefixed and additional help text is required to explain how to access traditional debugging commands.
<rdar://problem/17751929>
<rdar://problem/16953815>
<rdar://problem/16953841>
<rdar://problem/16930173>
<rdar://problem/16879028>
llvm-svn: 226068
We now verify that the debugger's input file is a valid terminal file descriptor before allowing the "gui" command to try to run.
Xcode would crash if you typed "gui" at the command line prior to this fix.
<rdar://problem/18775851>
llvm-svn: 226027
step through the complete function looking for any epilogue
instructions. If we find an epilogue sequence, re-instate
the correct unwind instructions if there is more code past
that epilogue -- this will correctly handle an x86 function
with multiple epilogues in it.
NB there is still a bug with the "eh_frame augmented"
UnwindPlans and mid-function epilogues. Looking at that next.
<rdar://problem/18863406>
llvm-svn: 225770
Variable was being declared as signed, but treated as unsigned at
every point of use.
Patch by Dan Sinclair
Differential Revision: http://reviews.llvm.org/D6897
llvm-svn: 225540
This new command will delete user defined regular commands, but not aliases. We still have "command unalias" to remove aliases as they are currently in different buckets. Appropriate error messages are displayed to inform the user when "command unalias" is used on removable user defined commands that points users to the "command delete" command.
Added a test to verify we can remove user defined commands and also verify that "command unalias" fails when used on a user defined command.
<rdar://problem/18248300>
llvm-svn: 225535
names can then be used in place of breakpoint id's or breakpoint id
ranges in all the commands that operate on breakpoints.
<rdar://problem/10103959>
llvm-svn: 224392
Summary:
If a stream contains an empty string, no need to append it to the output
(otherwise we end up with a blank line). Also, no need to print a status
message when the state changes to connected, as this string brings no
information -- "Process 0" does not mean anything to the user, and the
process being connected has no meaning either.
Test Plan:
Connect to a remote linux platform mode daemon with `platform select
remote-linux` followed by `platform connect ...`, create a target and
run it, observe the output. Also, run the full test suite (dosep.py).
Before:
(lldb) [...] connect, etc.
(lldb) r
Process 0 connected
Process 5635 launched: '/Users/sas/Source/test' (x86_64)
Process 5635 stopped
After:
(lldb) [...] connect, etc.
(lldb) r
Process 5635 launched: '/Users/sas/Source/test' (x86_64)
Process 5635 stopped
Reviewers: tfiala, vharron, clayborg
Subscribers: lldb-commits
Differential Revision: http://reviews.llvm.org/D6593
llvm-svn: 224188
section for x86_64 and i386 targets on Darwin systems. Currently only the
compact unwind encoding for normal frame-using functions is supported but it
will be easy handle frameless functions when I have a bit more free time to
test it. The LSDA and personality routines for functions are also retrieved
correctly for functions from the compact unwind section.
This new code is very fresh -- it passes the lldb testsuite and I've done
by-hand inspection of many functions and am getting correct behavior for all
of them. There may need to be some bug fixing over the next couple weeks as
I exercise and test it further. But I think it's fine right now so I'm
committing it.
<rdar://problem/13220837>
llvm-svn: 223625
in the "dummy-target". The dummy target breakpoints prime all future
targets. Breakpoints set before any target is created (e.g. breakpoints
in ~/.lldbinit) automatically get set in the dummy target. You can also
list, add & delete breakpoints from the dummy target using the "-D" flag,
which is supported by most of the breakpoint commands.
This removes a long-standing wart in lldb...
<rdar://problem/10881487>
llvm-svn: 223565
type format info
type summary info
type synthetic info
These commands all take an expression, evaluate it, and show which of the respective formatter (if any) applies to the result of the expression
Fixes rdar://12059317
llvm-svn: 223511
(e.g. breakpoints, stop-hooks) before we have any targets - for instance in
your ~/.lldbinit file. These will then get copied over to any new targets
that get created. So far, you can only make stop-hooks.
Breakpoints will have to learn to move themselves from target to target for
us to get them from no-target to new-target.
We should also make a command & SB API way to prime this ur-target.
llvm-svn: 222600
is treated as a string instead of a FileSpec.
OptionValueFileSpec::SetValueFromCString() passes the c string to
FileSpec::SetFile(str, true /* resolve */) - and with Zachary's
changes to FileSpec we're using llvm::sys::fs::make_absolute() to
do that "resolve" action now, where we used to use realpath().
One important difference between llvm::sys::fs::make_absolute and
realpath is that when they're handed a filename (no directory),
realpath prepends the current working directory *and if the file exists*,
returns that full path. If that file doesn't exist, the caller
uses the basename only.
llvm::sys::fs::make_absolute prepends the current working directory
regardless of whether it exists or not.
I considered having FileSpec::SetFile save the initial pathname,
call FileSpec::Resolve, and then check to see if the Resolve return
path exists - and if not, go back to the original one.
But instead I just went with changing 'target modules load' to treat its
filename argument as a string instead of a FileSpec. This brings it
in line with how 'target modules list' works.
<rdar://problem/18955416>
llvm-svn: 222498
Fixed the prompt to not include non-printable characters as it was hosing up the prompt when you ran "command regex foo" and entered multi-line editing mode.
Fixed error strings to include more complete descriptions when bad regular expressions are entered.
Removed the old IOHandlerLinesUpdated function as it is no longer needed (inheriting from IOHandlerDelegateMultiline takes care of what this function used to do).
llvm-svn: 222207
Fixed include:
- Change Platform::ResolveExecutable(...) to take a ModuleSpec instead of a FileSpec + ArchSpec to help resolve executables correctly when we have just a path + UUID (no arch).
- Add the ability to set the listener in SBLaunchInfo and SBAttachInfo in case you don't want to use the debugger as the default listener.
- Modified all places that use the SBLaunchInfo/SBAttachInfo and the internal ProcessLaunchInfo/ProcessAttachInfo to not take a listener as a parameter since it is in the launch/attach info now
- Load a module's sections by default when removing a module from a target. Since we create JIT modules for expressions and helper functions, we could end up with stale data in the section load list if a module was removed from the target as the section load list would still have entries for the unloaded module. Target now has the following functions to help unload all sections a single or multiple modules:
size_t
Target::UnloadModuleSections (const ModuleList &module_list);
size_t
Target::UnloadModuleSections (const lldb::ModuleSP &module_sp);
llvm-svn: 222167
Improvements include:
* Use of libedit's wide character support, which is imperfect but a distinct improvement over ASCII-only
* Fallback for ASCII editing path
* Support for a "faint" prompt clearly distinguished from input
* Breaking lines and insert new lines in the middle of a batch by simply pressing return
* Joining lines with forward and backward character deletion
* Detection of paste to suppress automatic formatting and statement completion tests
* Correctly reformatting when lines grow or shrink to occupy different numbers of rows
* Saving multi-line history, and correctly preserving the "tip" of history during editing
* Displaying visible ^C and ^D indications when interrupting input or sending EOF
* Fledgling VI support for multi-line editing
* General correctness and reliability improvements
llvm-svn: 222163
There were many issues with synchronous mode that we discovered when started to try and add a "batch" mode. There was a race condition where the event handling thread might consume events when in sync mode and other times the Process::WaitForProcessToStop() would consume them. This also led to places where the Process IO handler might or might not get popped when it needed to be.
llvm-svn: 220254
do that (RunCommandInterpreter, HandleCommands, HandleCommandsFromFile) to gather
the options into an options class. Also expose that to the SB API's.
Change the way the "-o" options to the lldb driver are processed so:
1) They are run synchronously - didn't really make any sense to run the asynchronously.
2) The stop on error
3) "quit" in one of the -o commands will not quit lldb - not the command interpreter
that was running the -o commands.
I added an entry to the run options to stop-on-crash, but I haven't implemented that yet.
llvm-svn: 219553
Reviewed at http://reviews.llvm.org/D5592
This patch gives LLDB some ability to interact with AddressSanitizer runtime library, on top of what we already have (historical memory stack traces provided by ASan). Namely, that's the ability to stop on an error caught by ASan, and access the report information that are associated with it. The report information is also exposed into SB API.
More precisely this patch...
adds a new plugin type, InstrumentationRuntime, which should serve as a generic superclass for other instrumentation runtime libraries, these plugins get notified when modules are loaded, so they get a chance to "activate" when a specific dynamic library is loaded
an instance of this plugin type, AddressSanitizerRuntime, which activates itself when it sees the ASan dynamic library or founds ASan statically linked in the executable
adds a collection of these plugins into the Process class
AddressSanitizerRuntime sets an internal breakpoint on __asan::AsanDie(), and when this breakpoint gets hit, it retrieves the report information from ASan
this breakpoint is then exposed as a new StopReason, eStopReasonInstrumentation, with a new StopInfo subclass, InstrumentationRuntimeStopInfo
the StopInfo superclass is extended with a m_extended_info field (it's a StructuredData::ObjectSP), that can hold arbitrary JSON-like data, which is the way the new plugin provides the report data
the "thread info" command now accepts a "-s" flag that prints out the JSON data of a stop reason (same way the "-j" flag works now)
SBThread has a new API, GetStopReasonExtendedInfoAsJSON, which dumps the JSON string into a SBStream
adds a test case for all of this
I plan to also get rid of the original ASan plugin (memory history stack traces) and use an instance of AddressSanitizerRuntime for that purpose.
Kuba
llvm-svn: 219546
output style can be customized. Change the built-in default to be
more similar to gdb's disassembly formatting.
The disassembly-format for a gdb-like output is
${addr-file-or-load} <${function.name-without-args}${function.concrete-only-addr-offset-no-padding}>:
The disassembly-format for the lldb style output is
{${function.initial-function}{${module.file.basename}`}{${function.name-without-args}}:\n}{${function.changed}\n{${module.file.basename}`}{${function.name-without-args}}:\n}{${current-pc-arrow} }{${addr-file-or-load}}:
The two backticks in the lldb style formatter triggers the sub-expression evaluation in
CommandInterpreter::PreprocessCommand() so you can't use that one as-is ... changing to
use ' characters instead of ` would work around that.
<rdar://problem/9885398>
llvm-svn: 219544
the user level. It adds the ability to invent new stepping modes implemented by python classes,
and to view the current thread plan stack and to some extent alter it.
I haven't gotten to documentation or tests yet. But this should not cause any behavior changes
if you don't use it, so its safe to check it in now and work on it incrementally.
llvm-svn: 218642
works, as do breakpoints, run and pause, display zeroth frame.
See
http://reviews.llvm.org/D5503
for a fuller description of the changes in this commit.
llvm-svn: 218596
Changes include:
- fix it so you can select the "host" platform using "platform select host"
- change all callbacks that create platforms to returns shared pointers
- fix TestImageListMultiArchitecture.py to restore the "host" platform by running "platform select host"
- Add a new "PlatformSP Platform::Find(const ConstString &name)" method to get a cached platform
- cache platforms that are created and re-use them instead of always creating a new one
llvm-svn: 218145
Also, in case they don't define any, change the default from "Run Python function <blah>" into "For more information run help <blah>"
The core issue here is that Python only allows one docstring per function, so we can't really attach both a short and a long help to the same command easily
There are alternatives but this is not a pressing enough concern to go through the motions quite yet
Fixes rdar://18322737
llvm-svn: 217795
We decided to use assmbly profiler instead of eh_frame for frame 0 because for compiler generated code, eh_frame is usually synchronous(a.k.a. only valid at call site); and we have no way to tell if it's asynchronous or not.
But for x86 & x86_64 compiler generated code:
1. clang & GCC describes all prologue instructions in eh_frame;
2. mid-function stack pointer altering instructions can be easily detected.
So we can grab eh_frame, and use assembly profiler to augment it into asynchronous unwind table.
This change also benefits hand-written assembly; eh_frame for hand-written assembly is often asynchronous,so we have a much better chance to successfully unwind through them.
Change by Tong Shen.
llvm-svn: 216406
This change modifies the 'process launch' --disable-aslr option to take a boolean argument. If the user directly specifies --disable-aslr {true,false}, that setting will control whether the process is launched with ASLR disabled accordingly. In the event that the setting is not explicitly made on the process launch command line, then the value is retrieved from the target.disable-aslr setting (i.e. settings show target.disable-aslr).
llvm-svn: 215996
Fixes include:
1 - added new FileSpec method: bool FileSpec::Readable()
2 - detect when an executable is not readable and give an appropriate error for:
(lldb) file /tmp/unreadablefile
3 - detect when a core file is not readable and give an appropriate error
4 - detect when a specified core file doesn't exist and give an appropriate error
<rdar://problem/17727734>
llvm-svn: 215741
This reverses out the options validators changes. We'll get these
back in once the changes to the output can be resolved.
Restores broken tests on FreeBSD, Linux, MacOSX.
Changes reverted: r212500, r212317, r212290.
llvm-svn: 212543
Windows uses a different process security model and does not have
a concept of process UID or GID. This patch makes these options
invalid on Windows. Attempting to specify these options when the
current platform is Windows will generate an error.
Reviewed by: Jim Ingham
Differential Revision: http://reviews.llvm.org/D4373
llvm-svn: 212500
The purpose of the OptionValidator is to determine, based on some
arbitrary set of conditions, whether or not a command option is
valid for a given debugger state. An example of this might be
to selectively disable or enable certain command options that
don't apply to a particular platform.
This patch contains no functional change, and does not actually
make use of an OptionValidator for any purpose yet. A follow-up
patch will begin to add the logic and users of OptionValidator.
Reviewed by: Greg Clayton, Jim Ingham
Differential Revision: http://reviews.llvm.org/D4369
llvm-svn: 212290
Replace adhoc inline implementation of llvm::array_lengthof in favour of the
implementation in LLVM. This is simply a cleanup change, no functional change
intended.
llvm-svn: 211868
lldb support. I'll be doing more testing & cleanup but I wanted to
get the initial checkin done.
This adds a new SBExpressionOptions::SetLanguage API for selecting a
language of an expression.
I added adds a new SBThread::GetInfoItemByPathString for retriving
information about a thread from that thread's StructuredData.
I added a new StructuredData class for representing
key-value/array/dictionary information (e.g. JSON formatted data).
Helper functions to read JSON and create a StructuredData object,
and to print a StructuredData object in JSON format are included.
A few Cocoa / Cocoa Touch data formatters were updated by Enrico
to track changes in iOS 8 / Yosemite.
Before we query a thread's extended information, the system runtime may
provide hints to the remote debug stub that it will use to retrieve values
out of runtime structures. I added a new SystemRuntime method
AddThreadExtendedInfoPacketHints which allows the SystemRuntime to add
key-value type data to the initial request that we send to the remote stub.
The thread-format formatter string can now retrieve values out of a thread's
extended info structured data. The default thread-format string picks up
two of these - thread.info.activity.name and thread.info.trace_messages.
I added a new "jThreadExtendedInfo" packet in debugserver; I will
add documentation to the lldb-gdb-remote.txt doc soon. It accepts
JSON formatted arguments (most importantly, "thread":threadnum) and
it returns a variety of information regarding the thread to lldb
in JSON format. This JSON return is scanned into a StructuredData
object that is associated with the thread; UI layers can query the
thread's StructuredData to see if key-values are present, and if
so, show them to the user. These key-values are likely to be
specific to different targets with some commonality among many
targets. For instance, many targets will be able to advertise the
pthread_t value for a thread.
I added an initial rough cut of "thread info" command which will print
the information about a thread from the jThreadExtendedInfo result.
I need to do more work to make this format reasonably.
Han Ming added calls into the pmenergy and pmsample libraries if
debugserver is run on Mac OS X Yosemite to get information about the
inferior's power use.
I added support to debugserver for gathering the Genealogy information
about threads, if it exists, and returning it in the jThreadExtendedInfo
JSON result.
llvm-svn: 210874
(lldb) file /bin/ls
(lldb) b malloc
(lldb) run
(lldb) process save-core /tmp/ls.core
Each ObjectFile plug-in now has the option to save core files by registering a new static callback.
llvm-svn: 210864
This fixes a number of trivial warnings in the Windows build. This is part of a larger effort to make the Windows build warning-free.
See http://reviews.llvm.org/D3914 for more details.
Change by Zachary Turner
llvm-svn: 209749
Add a callback that will allow an expression to be cancelled between the
expression evaluation stages (for the ClangUserExpressions.)
<rdar://problem/16790467>, <rdar://problem/16573440>
llvm-svn: 207944
This is a purely mechanical change explicitly casting any parameters for printf
style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux.
llvm-svn: 205607
This is a mechanical change addressing the various sign comparison warnings that
are identified by both clang and gcc. This helps cleanup some of the warning
spew that occurs during builds.
llvm-svn: 205390
You can either provide the function name, or function body text.
Also propagate the compilation error up from where it is checked so we can report compilation errors.
<rdar://problem/9898371>
llvm-svn: 205380
When there was no process, the expression options were set to not ignore breakpoints. This causes debug info to be generated and causes errors when evaluating simple expressions.
llvm-svn: 204745
(lldb) b puts
(lldb) expr -g -i0 -- (int)puts("hello")
First we will stop at the entry point of the expression before it runs, then we can step over a few times and hit the breakpoint in "puts", then we can continue and finishing stepping and fininsh the expression.
Main features:
- New ObjectFileJIT class that can be easily created for JIT functions
- debug info can now be enabled when parsing expressions
- source for any function that is run throught the JIT is now saved in LLDB process specific temp directory and cleaned up on exit
- "expr -g --" allows you to single step through your expression function with source code
<rdar://problem/16382881>
llvm-svn: 204682
This is a mechanical cleanup of unused functions. In the case where the
functions are referenced (in comment form), I've simply commented out the
functions. A second pass to clean that up is warranted.
The functions which are otherwise unused have been removed. Some of these were
introduced in the initial commit and not in use prior to that point!
NFC
llvm-svn: 204310
Multichar constants are not portable as the byte order is undefined. Use a
constant value instead. This avoids a warning when compiling with gcc 4.8+
(-Wmultichar) and makes the code more portable.
llvm-svn: 204110
for customizing "step-in" behavior (e.g. step-in doesn't step into code with no debug info), but also
the behavior of step-in/step-out and step-over when they step out of the frame they started in.
I also added as a proof of concept of this reworking a mode for stepping where stepping out of a frame
into a frame with no debug information will continue stepping out till it arrives at a frame that does
have debug information. This is useful when you are debugging callback based code where the callbacks
are separated from the code that initiated them by some library glue you don't care about, among other
things.
llvm-svn: 203747
ObjectFile::SetLoadAddress (Target &target,
lldb::addr_t value,
bool value_is_offset);
Now "value" is a slide if "value_is_offset" is true, and "value" is an image base address otherwise. All previous usage of this API was using slides.
Updated the ObjectFileELF and ObjectFileMachO SetLoadAddress methods to do the right thing.
Also updated the ObjectFileMachO::SetLoadAddress() function to not load __LINKEDIT when it isn't needed and to only load sections that belong to the executable object file.
llvm-svn: 201003
When a user says
type formatter add ... unsigned int
he most probably means to deal with the "unsigned int" type. However, given how the LLDB command parser works, that command will try to add the formatter to the TWO types 'unsigned' AND 'int'
Since this is unlikely to be what the user wants, warn about it, and suggest they can use quotes to override the debugger's understanding
llvm-svn: 200996
Also emit the "Executing commands" message so it properly only comes out when desired and so it comes out in the right place.
<rdar://problem/15992208>
llvm-svn: 200875
- empty lines in init files would repeat previous command and cause errors to be displayed
- all options to control showing the command, its output, if it should stop on error or continue, weren't being obeyed.
llvm-svn: 200860
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
The "type format add" command gets a new flag --type (-t). If you pass -t <sometype>, upon fetching the value for an object of your type,
LLDB will display it as-if it was of enumeration type <sometype>
This is useful in cases of non-contiguous enums where there are empty gaps of unspecified values, and as such one cannot type their variables as the enum type,
but users would still like to see them as-if they were of the enum type (e.g. DWARF field types with their user-reserved ranges)
The SB API has also been improved to handle both types of formats, and a test case is added
llvm-svn: 198105
So, rename the class for what it truly is: a FormattersContainer
Also do a bunch of related text substitutions in the interest of overall naming clarity
llvm-svn: 197795
While investigating test suite failures when running the test suite remotely, I noticed we had 3 copies of code that launched a process:
1 - in "process launch" command
2 - SBTarget::Launch() with args
3 - SBTarget::Launch() with SBLaunchInfo
"process launch" was launching through the platform if it was supported (this is needed for remote debugging) and the 2 and 3 were not.
Now all code is in one place.
llvm-svn: 197247
<rdar://problem/15314403>
This patch adds a new lldb_private::SectionLoadHistory class that tracks what shared libraries were loaded given a process stop ID. This allows us to keep a history of the sections that were loaded for a time T. Many items in history objects will rely upon the process stop ID in the future.
llvm-svn: 196557
lldb_private::Debugger was #including some "lldb/API" header files which causes tools (lldb-platform and lldb-gdbserver) that link against the internals only (no API layer) to fail to link depending on which calls were being used.
Also fixed the current working directory so that it gets set correctly for remote test suite runs. Now the remote working directory is set to: "ARCH/TESTNUM/..." where ARCH is the current architecture name and "TESTNUM" is the current test number.
Fixed the "lldb-platform" and "lldb-gdbserver" to not warn about mismatched visibility settings by having each have their own exports file which contains nothing. This forces all symbols to not be exported, and also quiets the linker warnings.
llvm-svn: 196141
Example code:
remote_platform = lldb.SBPlatform("remote-macosx");
remote_platform.SetWorkingDirectory("/private/tmp")
debugger.SetSelectedPlatform(remote_platform)
connect_options = lldb.SBPlatformConnectOptions("connect://localhost:1111");
err = remote_platform.ConnectRemote(connect_options)
if err.Success():
print >> result, 'Connected to remote platform:'
print >> result, 'hostname: %s' % (remote_platform.GetHostname())
src = lldb.SBFileSpec("/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework", False)
dst = lldb.SBFileSpec()
# copy src to platform working directory since "dst" is empty
err = remote_platform.Install(src, dst);
if err.Success():
print >> result, '%s installed successfully' % (src)
else:
print >> result, 'error: failed to install "%s": %s' % (src, err)
Implemented many calls needed in lldb-platform to be able to install a directory that contains symlinks, file and directories.
The remote lldb-platform can now launch GDB servers on the remote system so that remote debugging can be spawned through the remote platform when connected to a remote platform.
The API in SBPlatform is subject to change and will be getting many new functions.
llvm-svn: 195273
Remove the --do-read option, and always provide a small dump of memory at each match spot
Add a --dump-offset (-o) option, to specify a byte offset from which to start dumping relative to the matching address
The real solution is to actually provide the format options found on "memory read" and use those as the key to actually printing memory upon each find
That, however, requires a little refactoring work, so put this in for now until I get a chance to do the required shuffling around of moving parts
llvm-svn: 194600
Implement a "memory find" command for LLDB
This is still fairly rough around the edges but works well enough for simple scenarios where a chunk of text or a number are to be found within a certain range of memory, as in
mem find `buffer` `buffer+0x1000` -s "me" -c 5 -r
llvm-svn: 194544
It completes the job of using EvaluateExpressionOptions consistently throughout
the inferior function calling mechanism in lldb begun in Greg's patch r194009.
It removes a handful of alternate calls into the ClangUserExpression/ClangFunction/ThreadPlanCallFunction which
were there for convenience. Using the EvaluateExpressionOptions removes the need for them.
Using that it gets the --debug option from Greg's patch to work cleanly.
It also adds another EvaluateExpressionOption to not trap exceptions when running expressions. You shouldn't
use this option unless you KNOW your expression can't throw beyond itself. This is:
<rdar://problem/15374885>
At present this is only available through the SB API's or python.
It fixes a bug where function calls would unset the ObjC & C++ exception breakpoints without checking whether
they were set by somebody else already.
llvm-svn: 194182
iterators for LLDB's container data structures.
Iterable abstracts over the backing data structure,
ignoring keys for maps for example. It also provides
locking as a service so that the code
for (ThreadSP thread_sp : process->Threads())
{
// ... use thread_sp
}
takes the appropriate locks once, without having to
do anything else.
The salient advantages of this system are:
- Much simpler and idiomatic loop code
- Lock once instead of each time an element is fetched
- Less boilerplate to produce the iterators
The intent is that Iterable will replace Get...AtIndex
in most places, and that ForEach(), which solves the
same problem in a less-idiomatic way, be phased out in
favor of this approach.
I've added Iterables to ThreadList, TypeList, and
Process (which is really just forwarding to ThreadList).
llvm-svn: 194159
Cleaned up ClangUserExpression::Evaluate() to have only one variant that takes a "const EvaluateExpressionOptions& options" instead of taking many arguments.
The "--debug" option is designed to allow you to debug your expression by stopping at the first instruction (it enables --ignore-breakpoints=true and --unwind-on-error=false) and allowing you to step through your JIT code. It needs to be more integrated with the thread plan, so I am checking this in so Jim Ingham can make it happen.
llvm-svn: 194009
pure virtual base class and made StackFrame a subclass of that. As
I started to build on top of that arrangement today, I found that it
wasn't working out like I intended. Instead I'll try sticking with
the single StackFrame class -- there's too much code duplication to
make a more complicated class hierarchy sensible I think.
llvm-svn: 193983
defines a protocol that all subclasses will implement. StackFrame
is currently the only subclass and the methods that Frame vends are
nearly identical to StackFrame's old methods.
Update all callers to use Frame*/Frame& instead of pointers to
StackFrames.
This is almost entirely a mechanical change that touches a lot of
the code base so I'm committing it alone. No new functionality is
added with this patch, no new subclasses of Frame exist yet.
I'll probably need to tweak some of the separation, possibly moving
some of StackFrame's methods up in to Frame, but this is a good
starting point.
<rdar://problem/15314068>
llvm-svn: 193907
In almost all cases, the misuse is about "%lu" being used instead of the correct "%zu" (even though these are compatible on 64-bit platforms in practice). There are even a couple of cases where "%ld" (ie., signed int) is used instead of "%zu", and one where "%lu" is used instead of "%" PRIu64.
Fixes bug #17551.
Patch by "/dev/humancontroller"
llvm-svn: 193832
Fix a crasher that would occur if one tried to read memory as characters of some size != 1, e.g.
x -f c -s 10 buffer
This commit tries to do the right thing and uses the byte-size as the number of elements, unless both are specified and the number of elements is != 1
In this latter case (e.g. x -f c -s 10 -c 3 buffer) one could multiply the two and read 30 characters, but it seems a stretch in mind reading.
llvm-svn: 193659
Added a way to set hardware breakpoints from the "breakpoint set" command with the new "--hardware" option. Hardware breakpoints are not a request, they currently are a requirement. So when breakpoints are specified as hardware breakpoints, they might fail to be set when they are able to be resolved and should be used sparingly. This is currently hooked up for GDB remote debugging.
Linux and FreeBSD should quickly enable this feature if possible, or return an error for any breakpoints that are hardware breakpoint sites in the "virtual Error Process::EnableBreakpointSite (BreakpointSite *bp_site);" function.
llvm-svn: 192491
- By default, the above function will wait for at least one event
- Set wait_always=false to make the function return immediately if the process is already stopped
llvm-svn: 192301
Formats (as in "type format") are now included in categories
The only bit missing is caching formats along with synthetic children and summaries, which might be now desirable
llvm-svn: 192217
that all clients use them explicitly. This will hopefully
prevent any future confusion where things get cast to types
we don't expect.
<rdar://problem/15146458>
llvm-svn: 191984
DumpValueObject() 2.0
This checkin restores pre-Xcode5 functionality to the "po" (expr -O) command:
- expr now has a new --description-verbosity (-v) argument, which takes either compact or full as a value (-v is the same as -vfull)
When the full mode is on, "po" will show the extended output with type name, persistent variable name and value, as in
(lldb) expr -O -v -- foo
(id) $0 = 0x000000010010baf0 {
1 = 2;
2 = 3;
}
When -v is omitted, or -vcompact is passed, the Xcode5-style output will be shown, as in
(lldb) expr -O -- foo
{
1 = 2;
2 = 3;
}
- for a non-ObjectiveC object, LLDB will still try to retrieve a summary and/or value to display
(lldb) po 5
5
-v also works in this mode
(lldb) expr -O -vfull -- 5
(int) $4 = 5
On top of that, this is a major refactoring of the ValueObject printing code. The functionality is now factored into a ValueObjectPrinter class for easier maintenance in the future
DumpValueObject() was turned into an instance method ValueObject::Dump() which simply calls through to the printer code, Dump_Impl has been removed
Test case to follow
llvm-svn: 191694
to build out the symbol table as addresses are used, and implements
the mechanism for ELF to add stripped symbols from eh_frame.
Uses this mechanism to allow disassembly for addresses corresponding
to stripped symbols for ELF, and provide hooks to implement this for
PE COFF.
Also removes eSymbolContextTailCall in favor of an option for
ResolveSymbolContextForAddress for consistency with the documentation
for eSymbolContextEverything. Essentially, this is just an option for
interpreting the so_addr.
llvm-svn: 191307
This allows the PC to be directly changed to a different line.
It's similar to the example python script in examples/python/jump.py, except implemented as a builtin.
Also this version will track the current function correctly even if the target line resolves to multiple addresses. (e.g. debugging a templated function)
llvm-svn: 190572
- add default timeout of 10s (unil qPlatform_RunCommand supports timeout packets and CommandObjectPlatform is updated to read a timeout flag/setting)
- add a few tests for platform shell
llvm-svn: 189405
Summary:
This merge brings in the improved 'platform' command that knows how to
interface with remote machines; that is, query OS/kernel information, push
and pull files, run shell commands, etc... and implementation for the new
communication packets that back that interface, at least on Darwin based
operating systems via the POSIXPlatform class. Linux support is coming soon.
Verified the test suite runs cleanly on Linux (x86_64), build OK on Mac OS
X Mountain Lion.
Additional improvements (not in the source SVN branch 'lldb-platform-work'):
- cmake build scripts for lldb-platform
- cleanup test suite
- documentation stub for qPlatform_RunCommand
- use log class instead of printf() directly
- reverted work-in-progress-looking changes from test/types/TestAbstract.py that work towards running the test suite remotely.
- add new logging category 'platform'
Reviewers: Matt Kopec, Greg Clayton
Review: http://llvm-reviews.chandlerc.com/D1493
llvm-svn: 189295
- First, the watchpoint size was being cast to the
wrong type. This is primarily cosmetic, but
annoying.
- Second, the options for the watchpoint command
were not being initialized correctly, which led
to the watchpoint size sometimes having absurdly
large values. This caused watchpoints to fail to
be set in some cases.
<rdar://problem/12658775>
llvm-svn: 187169
plan providers from a "ThreadPlan *" to a "lldb::ThreadPlanSP". That was needed to fix
a bug where the ThreadPlanStepInRange wasn't checking with its sub-plans to make sure they
succeed before trying to proceed further. If the sub-plan failed and as a result didn't make
any progress, you could end up retrying the same failing algorithm in an infinite loop.
<rdar://problem/14043602>
llvm-svn: 186618
- MachO files now correctly extract the UUID all the time
- More file size and offset verification done for universal mach-o files to watch for truncated files
- ObjectContainerBSDArchive now supports enumerating all objects in BSD archives (.a files)
- lldb_private::Module() can not be properly constructed using a ModuleSpec for a .o file in a .a file
- The BSD archive plug-in shares its cache for GetModuleSpecifications() and the create callback
- Improved printing for ModuleSpec objects
llvm-svn: 186211
A long time ago we start with clang types that were created by the symbol files and there were many functions in lldb_private::ClangASTContext that helped. Later we create ClangASTType which contains a clang::ASTContext and an opauque QualType, but we didn't switch over to fully using it. There were a lot of places where we would pass around a raw clang_type_t and also pass along a clang::ASTContext separately. This left room for error.
This checkin change all type code over to use ClangASTType everywhere and I cleaned up the interfaces quite a bit. Any code that was in ClangASTContext that was type related, was moved over into ClangASTType. All code that used these types was switched over to use all of the new goodness.
llvm-svn: 186130
- ObjectFile::GetSymtab() and ObjectFile::ClearSymtab() no longer takes any flags
- Module coordinates with the object files and contain a unified section list so that object file and symbol file can share sections when they need to, yet contain their own sections.
Other cleanups:
- Fixed Symbol::GetByteSize() to not have the symbol table compute the byte sizes on the fly
- Modified the ObjectFileMachO class to compute symbol sizes all at once efficiently
- Modified the Symtab class to store a file address lookup table for more efficient lookups
- Removed Section::Finalize() and SectionList::Finalize() as they did nothing
- Improved performance of the detection of symbol files that have debug maps by excluding stripped files and core files, debug files, object files and stubs
- Added the ability to tell if an ObjectFile has been stripped with ObjectFile::IsStripped() (used this for the above performance improvement)
llvm-svn: 185990
The argument to -w (--category) in type * list is a regular expression
This caused unhappiness with the gnu-libstdc++ category because of the double ++
Now we check for exact textual match as-well-as regexp matching
llvm-svn: 184898
The semi-unofficial way of returning a status from a Python command was to return a string (e.g. return "no such variable was found") that LLDB would pick as a clue of an error having happened
This checkin changes that:
- SBCommandReturnObject now exports a SetError() call, which can take an SBError or a plain C-string
- script commands now drop any return value and expect the SBCommandReturnObject ("return object") to be filled in appropriately - if you do nothing, a success will be assumed
If your commands were relying on returning a value and having LLDB pick that up as an error, please change your commands to SetError() through the return object or expect changes in behavior
llvm-svn: 184893
This is a rewrite of the command history facility of LLDB
It takes the history management out of the CommandInterpreter into its own CommandHistory class
It reimplements the command history command to allow more combinations of options to work correctly (e.g. com hist -c 1 -s 5)
It adds a new --wipe (-w) option to command history to allow clearing the history on demand
It extends the lldbtest runCmd: and expect: methods to allow adding commands to history if need be
It adds a test case for the reimplemented facility
llvm-svn: 184140
If you type help command <word> <word> <word> <missingSubCommand> (e.g. help script import or help type summary fake), you will get help on the deepest matched command word (i.e. script or type summary in the examples)
Also, reworked the logic for commands to produce their help to make it more object-oriented
llvm-svn: 183822
Adding a new setting interpreter.stop-command-source-on-error that dictates a default behavior for whether command source should stop upon hitting an error
You can still override the setting for each individual invocation with the usual -e setting
llvm-svn: 183719
Add support for half-floats, as specified by IEEE-754-2008
With this checkin, you can now say:
(lldb) x/7hf foo
to read 7 half-floats at address foo
llvm-svn: 183716
level. Fixes a bug in "break set --source-pattern-regexp" when a shared library is
specified.
Also cleaned up the help text for --source-pattern-regexp so it is a little clearer.
<rdar://problem/14084261>
llvm-svn: 183476
lldb doesn't autocomplete objective C class methods. The regular expression was looking for strings that started with the completion string that was passed in. For objective C class methods, this string starts with "+" which wasn't being escaped. Added many other escapes that were missing just in case.
llvm-svn: 183470
Two things:
1) fixing a bug where memory read was not clearing the m_force flag after it was passed, so that subsequent memory reads would not need to be forced even if over boundary
2) adding a setting target.max-memory-read-size that you can set instead of the hardcoded 1024 bytes limit we had before
llvm-svn: 183276
If you want to define a formatter for "array of Foo of any size", ordinarily you would say
-x "Foo \[[0-9]+\]"
this checkin allows you to instead say "Foo[]" (or "Foo []") and LLDB will automatically create the regular expression and add the -x flag on your behalf
llvm-svn: 183272
command script import now does reloads - for real
If you invoke command script import foo and it detects that foo has already been imported, it will
- invoke reload(foo) to reload the module in Python
- re-invoke foo.__lldb_init_module
This second step is necessary to ensure that LLDB does not keep cached copies of any formatter, command, ... that the module is providing
Usual caveats with Python imports persist. Among these:
- if you have objects lurking around, reloading the module won't magically update them to reflect changes
- if module A imports module B, reloading A won't reload B
These are Python-specific issues independent of LLDB that would require more extensive design work
The --allow-reload (-r) option is maintained for compatibility with existing scripts, but is clearly documented as redundant - reloading is always enabled whether you use it or not
llvm-svn: 182977
A user request such as: memory read -fc -s10 -c1 *charPtrPtr would cause us to crash upon trying to read 1 char of size 10 from memory
This request is now translated into: memory read -fc -s1 -c10 *charPtrPtr (i.e. read 10 chars of size 1 from memory) which is probably also what the user originally wanted
llvm-svn: 182398
There are two settings:
target.load-script-from-symbol-file is a boolean that says load or no load (default: false)
target.warn-on-script-from-symbol-file is also a boolean, it says whether you want to be warned when a script file is not loaded due to security (default: true)
the auto loading on change for target.load-script-from-symbol-file is preserved
llvm-svn: 182336
This changes the setting target.load-script-from-symbol-file to be a ternary enum value:
default (the default value) will NOT load the script files but will issue a warning suggesting workarounds
yes will load the script files
no will not load the script files AND will NOT issue any warning
if you change the setting value from default to yes, that will then cause the script files to be loaded
(the assumption is you didn't know about the setting, got a warning, and quickly want to remedy it)
if you have a settings set command for this in your lldbinit file, be sure to change "true" or "false" into an appropriate "yes" or "no" value
llvm-svn: 182323
Name matching was working inconsistently across many places in LLDB. Anyone doing name lookups where you want to look for all types of names should used "eFunctionNameTypeAuto" as the sole name type mask. This will ensure that we get consistent "lookup function by name" results. We had many function calls using as mask like "eFunctionNameTypeBase | eFunctionNameTypeFull | eFunctionNameTypeMethod | eFunctionNameTypeSelector". This was due to the function lookup by name evolving over time, but as it stands today, use eFunctionNameTypeAuto when you want general name lookups. Either ModuleList::FindFunctions() or Module::FindFunctions() will figure out the right kinds of names to lookup and remove the "eFunctionNameTypeAuto" and replace it with the exact subset of what the name can be.
This checkin also changes eFunctionNameTypeAny over to use eFunctionNameTypeAuto to reflect this.
llvm-svn: 182179
"source list -n <func>" can now show more than one location that matches a function name. It will unique multiple of the same source locations so they don't get displayed. It also handles inline functions correctly.
llvm-svn: 182067
Make type summary add and breakpoint command add show an helpful prototype + argument reference when manually typing Python code for these elements
llvm-svn: 181968
Fixed "target symbols add" to correctly extract all module specifications from a dSYM file that is supplied and match the symbol file to a current target module using the UUID values if they are available.
This fixes the case where you add a dSYM file (like "foo.dSYM") which is for a renamed executable (like "bar"). In our case it was "mach_kernel.dSYM" which didn't match "mach_kernel.sys".
llvm-svn: 181916
Python breakpoint actions can return False to say that they don't want to stop at the breakpoint to which they are associated
Almost all of the work to support this notion of a breakpoint callback was in place, but two small moving parts were missing:
a) the SWIG wrapper was not checking the return value of the script
b) when passing a Python function by name, the call statement was dropping the return value of the function
This checkin addresses both concerns and makes this work
Care has been taken that you only keep running when an actual value of False has been returned, and that any other value (None included) means Stop!
llvm-svn: 181866
Provide a mechanism through which users can disable loading the Python scripts from dSYM files
This relies on a target setting: target.load-script-from-symbol-file which defaults to false ("do NOT load the script")
You need to set it to true before creating your target (or in your lldbinit file if you constantly rely on this feature) to allow the scripts to load
llvm-svn: 181709
Don't want about being unable to find a needed objective-c runtime
function when we're core file debugging and can't jit anything
anyway. Don't warn when quitting a debug session on a core file,
the program state can be reconstructed by re-running lldb on the
same core file again.
llvm-svn: 181653
Avoid a deadlock when using the OperatingSystemPython code and typing "process interrupt". There was a possible lock inversion between the target API lock and the process' thread list lock due to code trying to discard the thread list. This was fixed by adding a boolean to Process::Halt() that indicates if the thread plans should be discarded and doing it in the private state thread when we process the stopped state.
llvm-svn: 181651
<rdar://problem/13594769>
Main changes in this patch include:
- cleanup plug-in interface and use ConstStrings for plug-in names
- Modfiied the BSD Archive plug-in to be able to pick out the correct .o file when .a files contain multiple .o files with the same name by using the timestamp
- Modified SymbolFileDWARFDebugMap to properly verify the timestamp on .o files it loads to ensure we don't load updated .o files and cause problems when debugging
The plug-in interface changes:
Modified the lldb_private::PluginInterface class that all plug-ins inherit from:
Changed:
virtual const char * GetPluginName() = 0;
To:
virtual ConstString GetPluginName() = 0;
Removed:
virtual const char * GetShortPluginName() = 0;
- Fixed up all plug-in to adhere to the new interface and to return lldb_private::ConstString values for the plug-in names.
- Fixed all plug-ins to return simple names with no prefixes. Some plug-ins had prefixes and most ones didn't, so now they all don't have prefixed names, just simple names like "linux", "gdb-remote", etc.
llvm-svn: 181631
Recursive commands invocations are not currently supported by our CommandInterpreter
CommandScriptImport can actually be made to invoke itself recursively, so we need to work around that by clearing the m_exe_ctx
This is a short-term workaround, a more interesting solution would be to actually make sure recursive command invocations work properly
llvm-svn: 181537
std::string
Module::GetSpecificationDescription () const;
This returns the module as "/usr/lib/libfoo.dylib" for normal files (calls "std::string FileSpec::GetPath()" on m_file) but it also might include the object name in case the module is for a .o file in a BSD archive ("/usr/lib/libfoo.a(bar.o)"). Cleaned up necessary logging code to use it.
llvm-svn: 180717
unwind instructions for a function/symbol which contains that
address.
Update the unwind_diagnose.py script to use this instead of doing
image show-unwind by name to avoid cases where there are multiple
name definitions.
llvm-svn: 180079
to '-A'.
Add option '-a' / '--address' to disassemble which will find the
function that contains that address, and disassemble the entire function.
<rdar://problem/13436207>
llvm-svn: 179258
Introducing a negative cache for ObjCLanguageRuntime::LookupInCompleteClassCache()
This helps speed up the (common) case of us looking for classes that are hidden deep within Cocoa internals and repeatedly failing at finding type information for them.
In order for this to work, we need to clean this cache whenever debug information is added. A new symbols loaded event is added that is triggered with add-dsym (before modules loaded would be triggered for both adding modules and adding symbols).
Interested parties can register for this event. Internally, we make sure to clean the negative cache whenever symbols are added.
Lastly, ClassDescriptor::IsTagged() has been refactored to GetTaggedPointerInfo() that also (optionally) returns info and value bits. In this way, data formatters can share tagged pointer code instead of duplicating the required arithmetic.
llvm-svn: 178897
from the current Target, if there is one, else back off to getting
the currently selected platform from the Debugger (as it ws doing
previously.)
Remove code from DynamicLoaderDarwinKernel that was setting the platform
in both the Target and in the Debugger.
llvm-svn: 178836
“process attach” should ask the same questions as process launch if there is a current process.
“process connect” then “process launch” or “process attach” should actually work.
<rdar://problem/13524210>
<rdar://problem/13524208>
<rdar://problem/13488919>
llvm-svn: 178324
- Includes a stub for AVX support in the x86-64 register context and a failing test for register sets that are unavailable.
Thanks to Greg Clayton for his review feedback.
llvm-svn: 178252
ValueObjects themselves use DumpValueObjectOptions as the currency for the same purpose
The code to convert between these two units was replicated (to varying degrees of correctness) in several spots in the code
This checkin provides one and only one (and hopefully correct :-) entry point for this conversion
llvm-svn: 178044
Make register read and write accept $<regname> as valid.
This allows:
(lldb) reg read rbx
rbx = 0x0000000000000000
(lldb) reg read $rbx
rbx = 0x0000000000000000
(lldb) reg write $rbx 1
(lldb) reg read $rbx
rbx = 0x0000000000000001
to function correctly
It is not done at the RegisterContext level because we should keep the internal API clean of this user-friendly behavior and name registers appropriately.
If this ends up being needed in more places we can reconsider.
llvm-svn: 177961
Ensure that option -Y also works for expression as it does for frame variable
Also, if the user passes an explicit format specifier when printing a variable, override the summary's decision to hide the value.
This is required for scenarios like this to work:
(lldb) p/x c
(Class) $0 = 0x0000000100adb7f8 NSObject
Previously this would say:
(lldb) p/x c
(Class) $0 = NSObject
ignoring the explicit format specifier
llvm-svn: 177893
Made the "--reverse" option to "source list" also be able to use the "--count". This helps us implement support for regexp source list command:
(lldb) l -10
Which gets turned into:
(lldb) source list --reverse --count 10
Also simplified the code that is used to track showing more source from the last file and line.
llvm-svn: 176961
Calculate "can branch" using the MC API's rather than our hand-rolled regex'es.
As extra credit, allow setting the disassembly flavor for x86 based architectures to intel or att.
<rdar://problem/11319574>
<rdar://problem/9329275>
llvm-svn: 176392
StackFrame assumes m_sc is additive, but m_sc can lose its target. So now the SymbolContext::Clear() method takes a bool that indicates if the target should be cleared. Modified all existing code to properly set the bool argument.
llvm-svn: 175953
The notion of Crossref command has long been forgotten, and there is nothing using CommandObjectCrossref in the current LLDB codebase
However, this was causing a conflict with process plugins and command aliases ending up in an infinite loop under situations such as:
(lldb) command alias monitor process plugin packet monitor
(lldb) process att -n Calendar
Process 28709 stopped
Executable module set to "/Applications/Calendar.app/Contents/MacOS/Calendar".
Architecture set to: x86_64-apple-macosx.
(lldb) command alias monitor process plugin packet monitor
This fixes the loop (and consequent crash) by disposing of Crossref commands and related code
llvm-svn: 175831
- generate-vers.pl has to be called by cmake to generate the version number
- parallel builds not yet supported; dependency on clang must be explicitly specified
Tested on Linux.
- Building on Mac will require code-signing logic to be implemented.
- Building on Windows will require OS-detection logic and some selective directory inclusion
Thanks to Carlo Kok (who originally prepared these CMakefiles for Windows) and Ben Langmuir
who ported them to Linux!
llvm-svn: 175795
(lldb) frame variable
without first launching the inferior, you get:
error: invalid frame
this is misleading and should probably hint that there is no process. Adding this flag makes sure that we get:
error: invalid process
The difference between eFlagRequiresProcess and eFlagProcessMustBeLaunched is an open question.
llvm-svn: 175702
hitting auto-continue signals while running a thread plan would cause us to lose control of the debug
session.
<rdar://problem/12993641>
llvm-svn: 174793
Make the message when you hit an crash while evaluating an expression a little clearer, and mention "thread return -x".
rdar://problem/13110464
llvm-svn: 174095
Replacing the address argument type with address-expression in cases where StringToAddress() is used, and hence an expression can be passed where previously only a numeric address was allowed
This makes the documentation more clear and helps users discover that they can truly pass in an expression in these situations.
llvm-svn: 173753
Providing a compact display mode for "po" to use where the convenience variable name and the pointer value are both hidden.
This is for convenience when dealing with ObjC instances where the description often gets it right and the debugger-provided information is not useful to most people.
If you need either of these, "expr" will still show them.
llvm-svn: 173748
Flush the process when symbols are loaded/unloaded manually. This was going on in:
- "target modules load" command
- SBTarget::SetSectionLoadAddress(...)
- SBTarget::ClearSectionLoadAddress(...)
- SBTarget::SetModuleLoadAddress(...)
- SBTarget::ClearModuleLoadAddress(...)
llvm-svn: 173745
Data formatters now cache themselves.
This commit provides a new formatter cache mechanism. Upon resolving a formatter (summary or synthetic), LLDB remembers the resolution for later faster retrieval.
Also moved the data formatters subsystem from the core to its own group and folder for easier management, and done some code reorganization.
The ObjC runtime v1 now returns a class name if asked for the dynamic type of an object. This is required for formatters caching to work with the v1 runtime.
Lastly, this commit disposes of the old hack where ValueObjects had to remember whether they were queried for formatters with their static or dynamic type.
Now the ValueObjectDynamicValue class works well enough that we can use its dynamic value setting for the same purpose.
llvm-svn: 173728
Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary.
So I defined a new "lldb::offset_t" which should be used for all file offsets.
After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed.
Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections.
llvm-svn: 173463
Providing a special mode of operator for "memory read -f c-str" which actually works in most common cases
Where the old behavior would provide:
(lldb) mem read --format s `foo`
0x100000f5d: NULL
Now we do:
(lldb) mem read --format s `foo`
0x100000f5d: "hello world"
You can also specify a count and that many strings will be showed starting at the initial address:
(lldb) mem read -c 2 -f c-str `foo`
0x100000f1d: "hello world"
0x100000f29: "short"
llvm-svn: 173076
If there is any alive process being debugged, the user is asked for confirmation before quitting LLDB
This should prevent situations where the user mistakenly types "q" and LLDB slaughters their process without any mercy whatsoever
Since it can quickly get tedious, there is a new setting on the command interpreter to disable this and replicate the previous behavior
llvm-svn: 172757
controlled by the --unwind-on-error flag, and --ignore-breakpoint which separately controls behavior when a called
function hits a breakpoint. For breakpoints, we don't unwind, we either stop, or ignore the breakpoint, which makes
more sense.
Also make both these behaviors globally settable through "settings set".
Also handle the case where a breakpoint command calls code that ends up re-hitting the breakpoint. We were recursing
and crashing. Now we just stop without calling the second command.
<rdar://problem/12986644>
<rdar://problem/9119325>
llvm-svn: 172503
Fixed an issue with the auto loading of script resources in debug info files. Any platform can add support for this, and on MacOSX we allow dSYM files to contain python modules that get automatically loaded when a dSYM file is associated with an executable or shared library.
The modifications will now:
- Let the module locate the symbol file naturally instead of using a function that only works in certain cases. This helps us to locate the script resources as long as the dSYM file can be found.
- Don't try and do any of this if the script interpreter has scripting disabled.
- Allow more than one scripting resource to be found in a symbol file by returning the list
- Load the scripting resources when a symbol file is added via the "target symbols add" command.
- Be smarter about matching the dSYM mach-o file to an existing executable in the target images by stripping extensions on the symfile basname if needed.
llvm-svn: 172275
Adding useful formatting options to the expression (expr) command.
As a side effect of this change, the -d option now supports the same three-values enumeration that frame variables uses (run, don't run, none) instead of a boolean like it did previously
These options do not apply to print, p or po because these are aliased to not take any options.
In order to use them, use expression or expr.
llvm-svn: 171993
enum
{
//----------------------------------------------------------------------
// eFlagRequiresTarget
//
// Ensures a valid target is contained in m_exe_ctx prior to executing
// the command. If a target doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidTargetDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidTargetDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresTarget = (1u << 0),
//----------------------------------------------------------------------
// eFlagRequiresProcess
//
// Ensures a valid process is contained in m_exe_ctx prior to executing
// the command. If a process doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidProcessDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidProcessDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresProcess = (1u << 1),
//----------------------------------------------------------------------
// eFlagRequiresThread
//
// Ensures a valid thread is contained in m_exe_ctx prior to executing
// the command. If a thread doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidThreadDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidThreadDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresThread = (1u << 2),
//----------------------------------------------------------------------
// eFlagRequiresFrame
//
// Ensures a valid frame is contained in m_exe_ctx prior to executing
// the command. If a frame doesn't exist or is invalid, the command
// will fail and CommandObject::GetInvalidFrameDescription() will be
// returned as the error. CommandObject subclasses can override the
// virtual function for GetInvalidFrameDescription() to provide custom
// strings when needed.
//----------------------------------------------------------------------
eFlagRequiresFrame = (1u << 3),
//----------------------------------------------------------------------
// eFlagRequiresRegContext
//
// Ensures a valid register context (from the selected frame if there
// is a frame in m_exe_ctx, or from the selected thread from m_exe_ctx)
// is availble from m_exe_ctx prior to executing the command. If a
// target doesn't exist or is invalid, the command will fail and
// CommandObject::GetInvalidRegContextDescription() will be returned as
// the error. CommandObject subclasses can override the virtual function
// for GetInvalidRegContextDescription() to provide custom strings when
// needed.
//----------------------------------------------------------------------
eFlagRequiresRegContext = (1u << 4),
//----------------------------------------------------------------------
// eFlagTryTargetAPILock
//
// Attempts to acquire the target lock if a target is selected in the
// command interpreter. If the command object fails to acquire the API
// lock, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagTryTargetAPILock = (1u << 5),
//----------------------------------------------------------------------
// eFlagProcessMustBeLaunched
//
// Verifies that there is a launched process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBeLaunched = (1u << 6),
//----------------------------------------------------------------------
// eFlagProcessMustBePaused
//
// Verifies that there is a paused process in m_exe_ctx, if there
// isn't, the command will fail with an appropriate error message.
//----------------------------------------------------------------------
eFlagProcessMustBePaused = (1u << 7)
};
Now each command object contains a "ExecutionContext m_exe_ctx;" member variable that gets initialized prior to running the command. The validity of the target objects in m_exe_ctx are checked to ensure that any target/process/thread/frame/reg context that are required are valid prior to executing the command. Each command object also contains a Mutex::Locker m_api_locker which gets used if eFlagTryTargetAPILock is set. This centralizes a lot of checking code that was previously and inconsistently implemented across many commands.
llvm-svn: 171990
last source point listed.
Also fix the setting of the default file & line to the file containing main, when you do a plain "list".
<rdar://problem/12685226>
llvm-svn: 171945
Memory read's "repeat" behavior forgets "-t" option. It also formatted the type as hex bytes + ASCII. Now we revert to the default format when displaying types unless the user sets the format option manually.
llvm-svn: 170265
equality can be strict or loose and we want code to
explicitly choose one or the other.
Also renamed the Compare function to IsEqualTo, to
avoid confusion.
<rdar://problem/12856749>
llvm-svn: 170152
Emitting a warning when defining a summary or a synthetic provider and the function/class name provided does not correspond to a valid scripting object
Also using this chance to edit a few error messages from weird "internal error" markers to actual user-legible data!
llvm-svn: 170013
Added a "step-in-target" flag to "thread step-in" so if you have something like:
Process 28464 stopped
* thread #1: tid = 0x1c03, function: main , stop reason = breakpoint 1.1
frame #0: 0x0000000100000e08 a.out`main at main.c:62
61
-> 62 int A6 = complex (a(4), b(5), c(6)); // Stop here to step targetting b and hitting breakpoint.
63
and you want to get into "complex" skipping a, b and c, you can do:
(lldb) step -t complex
Process 28464 stopped
* thread #1: tid = 0x1c03, function: complex , stop reason = step in
frame #0: 0x0000000100000d0d a.out`complex at main.c:44
41
42 int complex (int first, int second, int third)
43 {
-> 44 return first + second + third; // Step in targetting complex should stop here
45 }
46
47 int main (int argc, char const *argv[])
llvm-svn: 170008
the option to print the runtime-specific description has been modified in the frame variable, memory read and expression command.
All three commands now support a --object-description option, with a shortcut of -O (uppercase letter o)
This is a breaking change:
frame variable used --objc as the long option name
expression used -o as a shortcut
memory read uses --objd as the long option name
Hopefully, most users won't be affected by the change since people tend to access "expression --object-description" under the alias "po" which still works
The test suite has been tweaked accordingly.
llvm-svn: 169961
- remove unused members
- add NO_PEDANTIC to selected Makefiles
- fix return values (removed NULL as needed)
- disable warning about four-char-constants
- remove unneeded const from operator*() declaration
- add missing lambda function return types
- fix printf() with no format string
- change sizeof to use a type name instead of variable name
- fix Linux ProcessMonitor.cpp to be 32/64 bit friendly
- disable warnings emitted by swig-generated C++ code
Patch by Matt Kopec!
llvm-svn: 169645
I modified the "Args::StringtoAddress(...)" function to be able to evaluate address expressions. This is now used for any command line arguments or options that takes addresses like:
memory read <addr> [<end-addr>]
memory write <addr>
breakpoint set --address <addr>
disassemble --start-address <addr> --end-address <addr>
It calls the expression parser to evaluate the address expression and will also work around the issue where the compiler doesn't like to add offsets to function pointers (which is what happens when you try to evaluate "main + 12"). So there is a temp fix in the Args::StringtoAddress() to work around this until we can get special compiler support for debug expressions with function pointers.
llvm-svn: 169556
- add new header lldb-python.h to be included before other system headers
- short term fix (eventually python dependencies must be cleaned up)
Patch by Matt Kopec!
llvm-svn: 169341
Cleaned up the option parsing code to always pass around the short options as integers. Previously we cast this down to "char" and lost some information. I recently added an assert that would detect duplicate short character options which was firing during the test suite.
This fix does the following:
- make sure all short options are treated as "int"
- make sure that short options can be non-printable values when a short option is not required or when an option group is mixed into many commands and a short option is not desired
- fix the help printing to "do the right thing" in all cases. Previously if there were duplicate short character options, it would just not emit help for the duplicates
- fix option parsing when there are duplicates to parse options correctly. Previously the option parsing, when done for an OptionGroup, would just start parsing options incorrectly by omitting table entries and it would end up setting the wrong option value
llvm-svn: 169189
For "target create" you can now specify "--no-dependents" to not track down and add all dependent shared libraries. This can be handy when doing manual symbolication. Also added the "--symfile" or "-s" for short so you can specify a module and a stand alone debug info file:
(lldb) target create --symfile /tmp/a.dSYM /usr/bin/a
Added the "--symfile" option to the "target modules add" for the same reason. These all help with manualy symbolication and expose functionality that was previously only available through the public API layer.
llvm-svn: 169023
Emit an error when using "target modules add PATH" where PATH points to a debug info only (dSYM) file.
Also added a "--uuid" option for "target modules add --uuid UUID" to locate and load a module by UUID if the host supports it.
llvm-svn: 168949
This commit does three things:
(a) introduces a new notification model for adding/removing/changing modules to a ModuleList, and applies it to the Target's ModuleList, so that we make sure to always trigger the right set of actions
whenever modules come and go in a target. Certain spots in the code still need to "manually" notify the Target for several reasons, so this is a work in progress
(b) adds a new capability to the Platforms: locating a scripting resources associated to a module. A scripting resource is a Python file that can load commands, formatters, ... and any other action
of interest corresponding to the loading of a module. At the moment, this is only implemented on Mac OS X and only for files inside .dSYM bundles - the next step is going to be letting
the frameworks themselves hold their scripting resources. Implementors of platforms for other systems are free to implement "the right thing" for their own worlds
(c) hooking up items (a) and (b) so that targets auto-load the scripting resources as the corresponding modules get loaded in a target. This has a few caveats at the moment:
- the user needs to manually add the .py file to the dSYM (soon, it will also work in the framework itself)
- if two modules with the same name show up during the lifetime of an LLDB session, the second one won't be able to load its scripting resource, but will otherwise work just fine
llvm-svn: 167569
x/9i
we actually calculated the size of 9 instructions. Then we multiplied it by the count again
to get the total amount we should fetch, so we thought 9 x86_64 instructions took over 1K
to fetch...
<rdar://problem/12649027>
llvm-svn: 167520
There was a generic catch-all type for path arguments
called "eArgTypePath," and a specialized version
called "eArgTypeFilename." It turns out all the
cases where we used eArgTypePath we could have
used Filename or we explicitly meant a directory.
I changed Path to DirectoryName, made it use the
directory completer, and rationalized the uses of
Path.
<rdar://problem/12559915>
llvm-svn: 166533
it to print the old and new values.
Temporarily disable the "out of scope" checking since it didn't work correctly, and was
not what people generally expected watchpoints to be doing.
llvm-svn: 166472
Added a new setting that allows a python OS plug-in to detect threads and provide registers for memory threads. To enable this you set the setting:
settings set target.process.python-os-plugin-path lldb/examples/python/operating_system.py
Then run your program and see the extra threads.
llvm-svn: 166244
<rdar://problem/12068650>
More fixes to how we handle paths that are used to create a target.
This modification centralizes the location where and how what the user specifies gets resolved. Prior to this fix, the TargetList::CreateTarget variants took a FileSpec object which meant everyone had the opportunity to resolve the path their own way. Now both CreateTarget variants take a "const char *use_exe_path" which allows the TargetList::CreateTarget to centralize where the resolving happens and "do the right thing".
llvm-svn: 166186
LLDB changes argv[0] when debugging a symlink. Now we have the notion of argv0 in the target settings:
target.arg0 (string) =
There is also the program argument that are separate from the first argument that have existed for a while:
target.run-args (arguments) =
When running "target create <exe>", we will place the untouched "<exe>" into target.arg0 to ensure when we run, we run with what the user typed. This has been added to the ProcessLaunchInfo and all other needed places so we always carry around the:
- resolved executable path
- argv0
- program args
Some systems may not support separating argv0 from the resolved executable path and the ProcessLaunchInfo needs to carry all of this information along so that each platform can make that decision.
llvm-svn: 166137
I added the ability for a process plug-in to implement custom commands. All the lldb_private::Process plug-in has to do is override:
virtual CommandObject *
GetPluginCommandObject();
This object returned should be a multi-word command that vends LLDB commands. There is a sample implementation in ProcessGDBRemote that is hollowed out. It is intended to be used for sending a custom packet, though the body of the command execute function has yet to be implemented!
llvm-svn: 165861
Then make the Thread a Broadcaster, and get it to broadcast when the selected frame is changed (but only from the Command Line) and when Thread::ReturnFromFrame
changes the stack.
Made the Driver use this notification to print the new thread status rather than doing it in the command.
Fixed a few places where people were setting their broadcaster class by hand rather than using the static broadcaster class call.
<rdar://problem/12383087>
llvm-svn: 165640
Also added a new option for "log enable" which is "--stack" which will print out a stack backtrace for each log line.
This was used to track down the leaking module issue I fixed last week.
llvm-svn: 165438
enabled after we'd found a few bugs that were caused by shadowed
local variables; the most important issue this turned up was
a common mistake of trying to obtain a mutex lock for the scope
of a code block by doing
Mutex::Locker(m_map_mutex);
This doesn't assign the lock object to a local variable; it is
a temporary that has its dtor called immediately. Instead,
Mutex::Locker locker(m_map_mutex);
does what is intended. For some reason -Wshadow happened to
highlight these as shadowed variables.
I also fixed a few obivous and easy shadowed variable issues
across the code base but there are a couple dozen more that
should be fixed when someone has a free minute.
<rdar://problem/12437585>
llvm-svn: 165269
loaded at a random offset).
To get the kernel's UUID and load address I need to send a kdp
packet so I had to implement the kernel relocation (and attempt to
find the kernel if none was provided to lldb already) in ProcessKDP
-- but this code really properly belongs in DynamicLoaderDarwinKernel.
I also had to add an optional Stream to ConnectRemote so
ProcessKDP::DoConnectRemote can print feedback about the remote kernel's
UUID, load address, and notify the user if we auto-loaded the kernel via
the UUID.
<rdar://problem/7714201>
llvm-svn: 164881
This checkin adds the capability for LLDB to load plugins from external dylibs that can provide new commands
It exports an SBCommand class from the public API layer, and a new SBCommandPluginInterface
There 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" command
For an example of how to make a plugin, refer to the fooplugin.cpp file in examples/plugins/commands
Caveats:
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-own
llvm-svn: 164865
We can now do:
Specify a path to a debug symbols file:
(lldb) add-dsym <path-to-dsym>
Go and download the dSYM file for the "libunc.dylib" module in your target:
(lldb) add-dsym --shlib libunc.dylib
Go and download the dSYM given a UUID:
(lldb) add-dsym --uuid <UUID>
Go and download the dSYM file for the current frame:
(lldb) add-dsym --frame
llvm-svn: 164806
top-of-tree. Removed all local patches and llvm.zip.
The intent is that fron now on top-of-tree will
always build against LLVM/Clang top-of-tree, and
that problems building will be resolved as they
occur. Stable release branches of LLDB can be
constructed as needed and linked to specific release
branches of LLVM/Clang.
llvm-svn: 164563
When attaching on ARM hosted debuggers we were incorrectly setting the triple to "arm-apple-ios". This was happening because in the post attach code, we would lookup the process info through the platform, and if successful, we would get the architecture of the process. This code uses sysctl() calls, but we can only get the CPU type, not the subtype, so we would get ARM for CPU type and nothing for the cpu subtype, so this would map to "arm-apple-ios". I fixed the code to get the cpu subtype from "hw.cpusubtype" which is what we really want for ARM, and not the architecture is already correct. "add-dsym" then works like a charm. I also improved the command output when the architecture changes to show the entire triple instead of just the arch name.
llvm-svn: 163868
Partial fix for the above radar where we now resolve dsym mach-o files within the dSYM bundle when using "add-dsym" through the platform.
llvm-svn: 163676
Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes:
- Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file".
- modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly
- Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was.
- modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile()
Cleaned up header includes a bit as well.
llvm-svn: 162860
- no setting auto completion
- very manual and error prone way of getting/setting variables
- tons of code duplication
- useless instance names for processes, threads
Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing".
llvm-svn: 162366
'add-dsym' (aka 'target symbols add') should display error messages when dsym file is not found
or the dsym uuid does not match any existing modules. Add TestAddDsymCommand.py test file.
llvm-svn: 162332
Add an lldb command line option to specify a core file: --core/-c.
For consistency, change the "target create" command to also use --core.
llvm-svn: 161993
Record the snapshot of our watched value when the watchpoint is set or hit.
And report the old/new values when watchpoint is triggered. Add some test scenarios.
llvm-svn: 161785
the expression returns nothing. There is now a
setting, "notify-void." When the user enables
that setting, lldb prints (void) if an expression's
result is void. Otherwise, lldb is silent.
<rdar://problem/11225150>
llvm-svn: 161600
keep a shared pointer to their disassembler. This
is important for the LLVM-C disassembler because
it needs to lock its parent in order to disassemble
itself.
This means that every interface that returned a
Disassembler* needs to return a DisassemblerSP, so
that the instructions and any external owners share
the same reference count on the object. I changed
all clients to use this shared pointer, which also
plugged a few leaks.
<rdar://problem/12002822>
llvm-svn: 161123
Convert from calling Halt in the lldb Driver.cpp's input reader's sigint handler to sending this AsyncInterrupt so it can be handled in the
event loop.
If you are attaching and get an async interrupt, abort the attach attempt.
Also remember to destroy the process if get interrupted while attaching.
Getting this to work also required handing the eBroadcastBitInterrupt in a few more places in Process WaitForEvent & friends.
<rdar://problem/10792425>
llvm-svn: 160903
UnwindPlans for a function. This specifically does not use any
previously-generated UnwindPlans so if any logging is performed
while creating the UnwindPlans, it will be repeated. This is
useful for when an lldb stack trace is not correct and you want
to gather diagnostic information from the user -- they can do
log enable -v lldb unwind, image show-unwind of the function, and
you'll get the full logging as the UnwindPlans are recreated.
llvm-svn: 160095
loop if "memory read" is run with the -t option and
the type name contains a keyword like "struct" that
isn't followed by a space. Now if a keyword isn't
followed by a space we continue searching after it,
instead of at the beginning of the type name.
Also optimized the code to not call strlen() on
a fixed set of statically-declared constant strings.
llvm-svn: 160016
Fixed a crasher in the "thread continue" code. There were many logic errors in the DoExecute function where thread index IDs were being used where the actual zero based thread index should have been used. This could cause crashes to happen since looking up a thread by index ID, when the zero based index of a thread should be used would return an empty thread shared pointer and cause a NULL deref.
llvm-svn: 159686
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
that forces all matches to be looked up. When --all
is not passed, and the current execution frame can
be used to narrow down the search, "target modules
lookup" will try searching in that specific frame
first. Only if nothing is turned up there will it
go on to search all modules.
This feature is currently enabled only for types.
llvm-svn: 158107
The output of 'register read' should be prettier.
Modify RegisterValue::Dump() to take an additional parameter:
uint32_t reg_name_right_align_at
which defaults to 0 (i.e., no alignment at all). Update the 'register read' command impl to pass 8
as the alignment to RegisterValue::Dump() method. If more sophisticated scheme is desired, we will
need to introduce an additional command option to 'register read' later on.
llvm-svn: 158039
Fix confusing error message about "expression did not evaluate to an address" when doing 'watchpoint set expression".
Instead of using 0 as the fail_value when invoking ValueObject::GetValueAsUnsigned(), modify the API to take an addition
bool pointer (defaults to NULL) to indicate success/failure of value conversion.
llvm-svn: 158016
Refactorings of watchpoint creation APIs so that SBTarget::WatchAddress(), SBValue::Watch(), and SBValue::WatchPointee()
now take an additional 'SBError &error' parameter (at the end) to contain the reason if there is some failure in the
operation. Update 'watchpoint set variable/expression' commands to take advantage of that.
Update existing test cases to reflect the API change and add test cases to verify that the SBError mechanism works for
SBTarget::WatchAddress() by passing an invalid watch_size.
llvm-svn: 157964
setting breakpoints. That's dangerous, since while we are setting a breakpoint,
the target might hit the dyld load notification, and start removing modules from
the list. This change adds a GetMutex accessor to the ModuleList class, and
uses it whenever we are accessing the target's ModuleList (as returned by GetImages().)
<rdar://problem/11552372>
llvm-svn: 157668
Supports the use-case scenario of immediately continuing the process once attached.
Add a simple completion test case from "process attach --con" to "process attach --continue ".
llvm-svn: 157361
Add default Process::GetWatchpointSupportInfo() impl which returns an error of "not supported".
Add "qWatchpointSupportInfo" packet to the gdb communication layer to support this, and modify TestWatchpointCommands.py to test it.
llvm-svn: 157345
"break set" commands to set this per breakpoint. Also, some CreateBreakpoint API's in the lldb_private
namespace had "internal" first and "skip_prologue" second. "internal should always be last. Fixed that.
rdar://problem/11484729
llvm-svn: 157225
<rdar://problem/11455913>
"target symbol add" should flush the cached frames
"register write" should flush the thread state in case registers modifications change stack
llvm-svn: 157042
For "process attach", make the success criterion as the inferior changes its state to eStateStopped.
Otherwise, mark it as a failure and say so.
llvm-svn: 157036
Add "--name" option to "image lookup" that will search both functions and symbols.
Also made all of the output from any of the "image lookup" commands be the same regardless of the lookup type (function name, symbol name, func or symbol, file and line, address, etc). The --verbose or -v option also will expand the results as needed and display things so they look the same.
llvm-svn: 156835
Also changed the defaults for SBThread::Step* to not delete extant plans.
Also added some test cases to test more complex stepping scenarios.
llvm-svn: 156667
Switch over to the "*-apple-macosx" for desktop and "*-apple-ios" for iOS triples.
Also make the selection process for auto selecting platforms based off of an arch much better.
llvm-svn: 156354
Correctly specify the LLDB_OPT_SET's that the 'shlib' command option belongs to by using a newly added macro like this:
#define LLDB_OPT_NOT_10 ( LLDB_OPT_SET_FROM(1, 10) & ~LLDB_OPT_SET_10 )
rdar://problem/11393864
llvm-svn: 156337
No one was using it and Locker(pthread_mutex_t *) immediately asserts for
pthread_mutex_t's that don't come from a Mutex anyway. Rather than try to make
that work, we should maintain the Mutex abstraction and not pass around the
platform implementation...
Make Mutex::Locker::Lock take a Mutex & or a Mutex *, and remove the constructor
taking a pthread_mutex_t *. You no longer need to call Mutex::GetMutex to pass
your mutex to a Locker (you can't in fact, since I made it private.)
llvm-svn: 156221
should be MasterPlans that want to stay on the plan stack. So make all plans NOT
MasterPlans by default and then have the SB API's and the CommandObjectThread step
commands set this explicitly.
Also added a "clean up" phase to the Thread::ShouldStop so that if plans get stranded
on the stack, we can remove them. This is done by adding an IsPlanStale method to the
thread plans, and if the plan can know that it is no longer relevant, it returns true,
and the plan and its sub-plans will get discarded.
llvm-svn: 156101
Error
Host::RunShellCommand (const char *command,
const char *working_dir,
int *status_ptr,
int *signo_ptr,
std::string *command_output_ptr,
uint32_t timeout_sec);
This will allow us to use this functionality in the host lldb_private::Platform, and also use it in our lldb-platform binary. It leverages the existing code in Host::LaunchProcess and ProcessLaunchInfo.
llvm-svn: 154730
Cleaned up the Mutex::Locker and the ReadWriteLock classes a bit.
Also cleaned up the GDBRemoteCommunication class to not have so many packet functions. Used the "NoLock" versions of send/receive packet functions when possible for a bit of performance.
llvm-svn: 154458
Work around a deadlocking issue where "SBDebugger::MemoryPressureDetected ()" is being called and is causing a deadlock. We now just try and get the lock when trying to trim down the unique modules so we don't deadlock debugger GUI programs until we can find the root cause.
llvm-svn: 154339
Symbol files (dSYM files on darwin) can now be specified during program execution:
(lldb) target symbols add /path/to/symfile/a.out.dSYM/Contents/Resources/DWARF/a.out
This command can be used when you have a debug session in progress and want to add symbols to get better debug info fidelity.
llvm-svn: 153693
Jim Ingham