Added the "frame diagnose" command and use its output to make crash info better.

When a process stops due to a crash, we get the crashing instruction and the
crashing memory location (if there is on

Added the "frame diagnose" command and use its output to make crash info better.

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

show more ...

Typo corrections identified by codespell

Submitted by [email protected]; I fixed a couple of nearby errors and
incorrect changes in the patch.

llvm.org/pr27634

llvm-svn: 275983

second pass over removal of Mutex and Condition

llvm-svn: 270024

Keep original source path and mapped path in LineEntry

Summary:
The "file" variable in a LineEntry was mapped using target.source-map, except when stepping through inlined code. This patch adds a ne

Keep original source path and mapped path in LineEntry

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

show more ...

When building the list of variables we're going to write "using $_lldb_local_vars"
statements for, be sure not to include variables that have no locations. We wouldn't
be able to realize them, and

When building the list of variables we're going to write "using $_lldb_local_vars"
statements for, be sure not to include variables that have no locations. We wouldn't
be able to realize them, and that will cause all expressions to fail.

llvm-svn: 267500

show more ...

Fix StackFrame::GetVariables(...) function that was broken by 261858 when lambda functions were added to Block::AppendBlockVariables(). The Stackframe::GetVariables(...) function should get all varia

Fix StackFrame::GetVariables(...) function that was broken by 261858 when lambda functions were added to Block::AppendBlockVariables(). The Stackframe::GetVariables(...) function should get all variables regardless if they are in scope.

This wasn't caught by the test suite so I added a test for it.

llvm-svn: 267478

show more ...

Improve the 'type lookup' command such that it guesses to use the current's frame language as the one to start searching from.

llvm-svn: 263592

Add support for DW_OP_push_object_address in dwarf expressions

Additionally fix the type of some dwarf expression where we had a
confusion between scalar and load address types after a dereference.

Add support for DW_OP_push_object_address in dwarf expressions

Additionally fix the type of some dwarf expression where we had a
confusion between scalar and load address types after a dereference.

Differential revision: http://reviews.llvm.org/D17604

llvm-svn: 262014

show more ...

Handle the case when a variable is only valid in part of the enclosing scope

DWARF stores this information in the DW_AT_start_scope attribute. This
CL add support for this attribute and also changes

Handle the case when a variable is only valid in part of the enclosing scope

DWARF stores this information in the DW_AT_start_scope attribute. This
CL add support for this attribute and also changes the functions
displaying frame variables to only display the variables currently in
scope.

Differential revision: http://reviews.llvm.org/D17449

llvm-svn: 261858

show more ...

Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes.

llvm-svn: 261242

Add -Wimplicit-fallthrough command line option to clang in
the xcode project file to catch switch statements that have a
case that falls through unintentionally.

Define LLVM_FALLTHROUGH to indicate

Add -Wimplicit-fallthrough command line option to clang in
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

show more ...

Fix a thinko in StackFrame::GetInScopeVariableList.

Reviewers: clayborg

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D16745

llvm-svn: 259607

[LLDB] Switch to assembly view if source is moved

Reviewers: clayborg, jingham, jasonmolenda.
Subscribers: jaydeep, bhushan, sagar, nitesh.jain,lldb-commits.
Differential Revision: http://reviews.ll

[LLDB] Switch to assembly view if source is moved

Reviewers: clayborg, jingham, jasonmolenda.
Subscribers: jaydeep, bhushan, sagar, nitesh.jain,lldb-commits.
Differential Revision: http://reviews.llvm.org/D12877

llvm-svn: 254588

show more ...

Fix up LLDB for a change in the way clang represents anonymous unions such that the 'frame variable' command can still find the members of such union as if they were top-level variables in the curren

Fix up LLDB for a change in the way clang represents anonymous unions such that the 'frame variable' command can still find the members of such union as if they were top-level variables in the current scope

llvm-svn: 253613

show more ...

Use eAddressClassCode for address lookup for opcodes for stack frames

It is required because of the following edge case on arm:

bx <addr> Non-tail call in a no return function
[data-pool] Marked

Use eAddressClassCode for address lookup for opcodes for stack frames

It is required because of the following edge case on arm:

bx <addr> Non-tail call in a no return function
[data-pool] Marked with $d mapping symbol

The return address of the function call will point to the data pool but
we have to treat it as code so the StackFrame can calculate the symbols
correctly.

Differential revision: http://reviews.llvm.org/D12556

llvm-svn: 246958

show more ...

Set the default language to use when evaluating to that of the frame's CU.

* Use the frame's context (instead of just the target's) when evaluating,
so that the language of the frame's CU can be u

Set the default language to use when evaluating to that of the frame's CU.

* 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

show more ...

Final bit of type system cleanup that abstracts declaration contexts into lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions.

Create a new "lldb_

Final bit of type system cleanup that abstracts declaration contexts into lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions.

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

show more ...

Fix resolution conflict between global and class static variables in C++

llvm-svn: 245381

Don't #include "lldb-python.h" from anywhere.

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,

Don't #include "lldb-python.h" from anywhere.

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

show more ...

Remove duplicated code for synthetic array members.

Summary:
The code for GetSyntheticArrayMemberFromPointer and
GetSyntheticArrayMemberFromArray was identical, so just collapse the
the methods into

Remove duplicated code for synthetic array members.

Summary:
The code for GetSyntheticArrayMemberFromPointer and
GetSyntheticArrayMemberFromArray was identical, so just collapse the
the methods into one.

Reviewers: granata.enrico, clayborg

Reviewed By: clayborg

Subscribers: lldb-commits

Differential Revision: http://reviews.llvm.org/D7911

llvm-svn: 230708

show more ...

Change the default disassembly format again. First attempt at
changing it was in r219544 - after living on that for a few
months, I wanted to take another crack at this.

The disassembly-format set

Change the default disassembly format again. First attempt at
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

show more ...

Get rid of Debugger::FormatPrompt() and replace it with the new FormatEntity class.

Why? Debugger::FormatPrompt() would run through the format prompt every time and parse it and emit it piece by pie

Get rid of Debugger::FormatPrompt() and replace it with the new FormatEntity class.

Why? Debugger::FormatPrompt() would run through the format prompt every time and parse it and emit it piece by piece. It also did formatting differently depending on which key/value pair it was parsing.

The new code improves on this with the following features:
1 - Allow format strings to be parsed into a FormatEntity::Entry which can contain multiple child FormatEntity::Entry objects. This FormatEntity::Entry is a parsed version of what was previously always done in Debugger::FormatPrompt() so it is more efficient to emit formatted strings using the new parsed FormatEntity::Entry.
2 - Allows errors in format strings to be shown immediately when setting the settings (frame-format, thread-format, disassembly-format
3 - Allows auto completion by implementing a new OptionValueFormatEntity and switching frame-format, thread-format, and disassembly-format settings over to using it.
4 - The FormatEntity::Entry for each of the frame-format, thread-format, disassembly-format settings only replaces the old one if the format parses correctly
5 - Combines all consecutive string values together for efficient output. This means all "${ansi.*}" keys and all desensitized characters like "\n" "\t" "\0721" "\x23" will get combined with their previous strings
6 - ${*.script:} (like "${var.script:mymodule.my_var_function}") have all been switched over to use ${script.*:} "${script.var:mymodule.my_var_function}") to make the format easier to parse as I don't believe anyone was using these format string power user features.
7 - All key values pairs are defined in simple C arrays of entries so it is much easier to add new entries.

These changes pave the way for subsequent modifications where we can modify formats to do more (like control the width of value strings can do more and add more functionality more easily like string formatting to control the width, printf formats and more).

llvm-svn: 228207

show more ...

Fix a corner case with the handling of noreturn functions.
If a noreturn function was the last function in a section,
we wouldn't correctly back up the saved-pc value into the
correct section leading

Fix a corner case with the handling of noreturn functions.
If a noreturn function was the last function in a section,
we wouldn't correctly back up the saved-pc value into the
correct section leading to us showing the wrong function in
the backtrace.

Also add a backtrace test with an attempt to elicit this
particular layout. It happens to work out with clang -Os
but other compilers may not quite get the same layout I'm
getting at that opt setting. We'll still be exercising the
basic noreturn handling in the unwinder even if we don't get
one function at the very end of a section.

<rdar://problem/16051613>

llvm-svn: 221575

show more ...

Expose the type-info flags at the public API layer. These flags provide much more informational content to consumers of the LLDB API than the existing TypeClass. Part of the fix for rdar://18517593

Expose the type-info flags at the public API layer. These flags provide much more informational content to consumers of the LLDB API than the existing TypeClass. Part of the fix for rdar://18517593

llvm-svn: 220322

show more ...

Add a new disassembly-format specification so that the disassembler
output style can be customized. Change the built-in default to be
more similar to gdb's disassembly formatting.

The disassembly-f

Add a new disassembly-format specification so that the disassembler
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

show more ...