169 Commits

Author SHA1 Message Date
Sean Callanan 807ee2ff69 Cleaned up some of the "frame diagnose" code to use Operands as currency.
Also added some utility functions around Operands to make code easier and more
compact to write.

llvm-svn: 281398
2016-09-13 21:18:27 +00:00
Ilia K 4f730dc750 Fix about a dozen compile warnings
Summary:
It fixes the following compile warnings:
1. '0' flag ignored with precision and ‘%d’ gnu_printf format
2. enumeral and non-enumeral type in conditional expression
3. format ‘%d’ expects argument of type ‘int’, but argument 4 has type ...
4. enumeration value ‘...’ not handled in switch
5. cast from type ‘const uint64_t* {aka ...}’ to type ‘int64_t* {aka ...}’ casts away qualifiers
6. extra ‘;’
7. comparison between signed and unsigned integer expressions
8. variable ‘register_operand’ set but not used
9. control reaches end of non-void function

Reviewers: jingham, emaste, zturner, clayborg

Subscribers: lldb-commits

Differential Revision: https://reviews.llvm.org/D24331

llvm-svn: 281191
2016-09-12 05:25:33 +00:00
Jason Molenda 0b4c26b2cc I'm experimenting with changing how the mixed source & assembly
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
2016-09-08 05:12:41 +00:00
Kate Stone b9c1b51e45 *** This commit represents a complete reformatting of the LLDB source code
*** to conform to clang-format’s LLVM style.  This kind of mass change has
*** two obvious implications:

Firstly, merging this particular commit into a downstream fork may be a 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
2016-09-06 20:57:50 +00:00
Pavel Labath 5cf1ece222 Fix build breakage in r280692
The commit introduced an array of const objects, which libstdc++ does not like. Make the object
non-const.

Also fix a compiler warning while I'm in there.

llvm-svn: 280697
2016-09-06 10:04:22 +00:00
Sean Callanan 4740a734bb 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
2016-09-06 04:48:36 +00:00
Ed Maste 75500e72bb Typo corrections identified by codespell
Submitted by giffunip@yahoo.com; I fixed a couple of nearby errors and
incorrect changes in the patch.

llvm.org/pr27634

llvm-svn: 275983
2016-07-19 15:28:02 +00:00
Saleem Abdulrasool bb19a13c0b second pass over removal of Mutex and Condition
llvm-svn: 270024
2016-05-19 05:13:57 +00:00
Ted Woodward 911d57840a 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
2016-05-11 22:46:53 +00:00
Jim Ingham cef461772e 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
2016-04-26 00:29:59 +00:00
Greg Clayton a32532bfa5 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
2016-04-25 21:54:10 +00:00
Enrico Granata 592afe73ad 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
2016-03-15 21:50:51 +00:00
Tamas Berghammer 5b42c7aa25 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
2016-02-26 14:21:10 +00:00
Tamas Berghammer 72ac8a840f 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
2016-02-25 12:23:37 +00:00
Eugene Zelenko d70a6e71a9 Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Target; other minor fixes.
llvm-svn: 261242
2016-02-18 18:52:47 +00:00
Jason Molenda 62e0681afb 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
2016-02-16 04:14:33 +00:00
Siva Chandra b90168ff41 Fix a thinko in StackFrame::GetInScopeVariableList.
Reviewers: clayborg

Subscribers: lldb-commits

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

llvm-svn: 259607
2016-02-02 23:49:41 +00:00
Mohit K. Bhakkad 8be7499507 [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
2015-12-03 04:56:16 +00:00
Enrico Granata 46252398f0 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
2015-11-19 22:28:58 +00:00
Tamas Berghammer 25b9f7ebd3 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
2015-09-07 09:58:09 +00:00
Dawn Perchik 009d110de4 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
2015-09-04 01:02:30 +00:00
Greg Clayton 99558cc424 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
2015-08-24 23:46:31 +00:00
Paul Herman 10bc1a4e83 Fix resolution conflict between global and class static variables in C++
llvm-svn: 245381
2015-08-18 22:46:57 +00:00
Zachary Turner 1124045ac7 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
2015-05-29 17:41:47 +00:00
Bruce Mitchener 11d86362ae 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
2015-02-26 23:55:39 +00:00