Commit Graph

59 Commits

Author SHA1 Message Date
Zachary Turner c156427ded Don't allow direct access to StreamString's internal buffer.
This is a large API change that removes the two functions from
StreamString that return a std::string& and a const std::string&,
and instead provide one function which returns a StringRef.

Direct access to the underlying buffer violates the concept of
a "stream" which is intended to provide forward only access,
and makes porting to llvm::raw_ostream more difficult in the
future.

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

llvm-svn: 287152
2016-11-16 21:15:24 +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
Sean Callanan 799a3fc60b Fixed a problem where we failed to get the size of an Objective-C type.
<rdar://problem/27897056>

llvm-svn: 279098
2016-08-18 17:45:50 +00:00
Adrian Prantl 6aeba89e89 Support floating point values in 128-bit SSE vector registers
The System-V x86_64 ABI requires floating point values to be passed
in 128-but SSE vector registers (xmm0, ...). When printing such a
variable this currently yields an <invalid load address>.

This patch makes LLDB's DWARF expression evaluator accept 128-bit
registers as scalars. It also relaxes the check that the size of the
result of the DWARF expression be equal to the size of the variable to a
greater-than. DWARF defers to the ABI how smaller values are being placed
in a larger register.

Implementation note: I found the code in Value::SetContext() that changes
the m_value_type after the fact to be questionable. I added a sanity check
that the Value's memory buffer has indeed been written to (this is
necessary, because we may have a scalar value in a vector register), but
really I feel like this is the wrong place to be setting it.

Reviewed by Greg Clayton.

http://reviews.llvm.org/D17897
rdar://problem/24944340

llvm-svn: 262947
2016-03-08 18:35:09 +00:00
Todd Fiala 6993abff14 Revert "Fix bug with register values byte order in expression evaluation."
This reverts commit r262041, which caused asserts starting yesterday on the OS X testbot.

See details in:
https://llvm.org/bugs/show_bug.cgi?id=26758

llvm-svn: 262156
2016-02-27 22:48:50 +00:00
Chaoren Lin b6f76b3d47 Register value is not necessarily scalar.
Reviewers: aidan.dodds, mamai

Subscribers: lldb-commits

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

llvm-svn: 262081
2016-02-26 22:12:35 +00:00
Aidan Dodds 5ba2b2af6e Fix bug with register values byte order in expression evaluation.
The evaluation of expressions containing register values was broken for targets for which endianness differs from host.

Committed on behalf of: mamai <marianne.mailhot.sarrasin@gmail.com>

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

llvm-svn: 262041
2016-02-26 17:40:50 +00:00
Sean Callanan edd508b362 Fixed a bug where the size of a type was used instead of the size of a pointer.
llvm-svn: 252655
2015-11-10 21:48:05 +00:00
Jim Ingham 2c38141423 Add "zero_memory" option to IRMemoryMap::FindSpace & IRMemoryMap::Malloc. Zero out
the Expression ResultVariable so it's in a known initial state.

llvm-svn: 252072
2015-11-04 20:32:27 +00:00
Eugene Zelenko 315b688457 Fix Clang-tidy modernize-use-override warnings in some files in source; other minor fixes.
llvm-svn: 251309
2015-10-26 17:00:13 +00:00
Sean Callanan 9fda9d2177 Add PersistentVariableDelegate to handle language-specific dematerialization.
The concept here is that languages may have different ways of communicating
results.  In particular, languages may have different names for their result
variables and in fact may have multiple types of result variables (e.g.,
error results).  Materializer was tied to one specific model of result handling.

Instead, now UserExpressions can register their own handlers for the result
variables they inject.  This allows language-specific code in Materializer to
be moved into the expression parser plug-in, and it simplifies Materializer.
These delegates are subclasses of PersistentVariableDelegate.

PersistentVariableDelegate can provide the name of the result variable, and is
notified when the result variable is populated.  It can also be used to touch
persistent variables if need be, updating language-specific state.  The
UserExpression owns the delegate and can decide on its result based on
consulting all of its (potentially multiple) delegates.

The user expression itself now makes the determination of what the final result
of the expression is, rather than relying on the Materializer, and I've added a
virtual function to UserExpression to allow this.

llvm-svn: 249233
2015-10-03 09:09:01 +00:00
Sean Callanan a994b0b273 Made GetScratchTypeSystemForLanguage return an error if desired.
Also made it not store nullptrs in its TypeSystemMap, so it will retry to make
the AST context if it errored out last time.

llvm-svn: 249167
2015-10-02 18:40:30 +00:00
Sean Callanan 9301ec1191 Eliminated redundant "constructors" for ClangExpressionVariable.
The ClangExpressionVariable::CreateVariableInList functions looked cute, but                                                                                                                                           
caused more confusion than they solved.  I removed them, and instead made sure                                                                                                                                         
that there are adequate facilities for easily adding newly-constructed                                                                                                                                                 
ExpressionVariables to lists.      

I also made some of the constructors that are common be generic, so that it's
possible to construct expression variables from generic places (like the ABI and
ValueObject) without having to know the specifics about the class.

llvm-svn: 249095
2015-10-01 23:07:06 +00:00
Sean Callanan 8f1f9a1be3 Now persistent expression data no longer lives with the Target, but rather with
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
2015-09-30 19:57:57 +00:00
Sean Callanan e6f4a8261a Removed a bunch of dependencies of Materializer on ClangUserExpression.
Instead we now just generically use UserExpression.

llvm-svn: 248842
2015-09-29 22:52:50 +00:00
Sean Callanan 4dbb271fcc Moved more Clang-specific parts of the expression parser into the Clang plugin.
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
2015-09-25 20:35:58 +00:00
Sean Callanan c608d206c7 Removed a needless cast to ClangExpressionVariable.
llvm-svn: 247910
2015-09-17 18:19:12 +00:00
Sean Callanan 3820e9cd17 ExpressionVariable now uses llvm::cast() instead of As...() for RTTI.
As part of our overall switch from hand-rolling RTTI to using LLVM-compatible
methods, I've done the same for ExpressionVariable.  The main documentation for
how to do this is in TypeSystem.h, so I've simply referred to that.

llvm-svn: 247085
2015-09-08 22:23:39 +00:00
Sean Callanan bc8ac34e61 This patch separates the generic portion of ClangExpressionVariable, which
stores information about a variable that different parts of LLDB use, from the
compiler-specific portion that only the expression parser cares about.

http://reviews.llvm.org/D12602

llvm-svn: 246871
2015-09-04 20:49:51 +00:00
Sean Callanan 30e339749f Jim told me about a cleaner way to include headers from plug-ins.
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
2015-09-03 00:48:23 +00:00
Sean Callanan e33724f371 In preparation for factoring persistent variables into a generic part and a
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
2015-09-03 00:35:46 +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
Greg Clayton a1e5dc86a6 ClangASTType is now CompilerType.
This is more preparation for multiple different kinds of types from different compilers (clang, Pascal, Go, RenderScript, Swift, etc).

llvm-svn: 244689
2015-08-11 22:53:00 +00:00
Greg Clayton 358cf1ea30 Resubmitting 240466 after fixing the linux test suite failures.
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
2015-06-25 21:46:34 +00:00
Zachary Turner af0f45f1c9 Don't #include ClangPersistentVariables.h from Process.h
Nothing from this header file was even being referenced in
Process.h anyway, so it was a completely unnecessary include.

llvm-svn: 231131
2015-03-03 21:05:17 +00:00
Enrico Granata 1cd5e921e1 Preparatory infrastructural work to support dynamically determining sizes of ObjC types via the runtime
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
2015-01-28 00:07:51 +00:00
Sylvestre Ledru f6102892ef Fix some typos:
* transfered => transferred
* unkown => unknown
* sucessfully => successfully

llvm-svn: 215367
2014-08-11 18:06:28 +00:00
Sean Callanan 4640a01c1c Fixed a flipped conditional when writing back the
values of variables in the Materializer.

The Materializer should not write the variable
back if its new value is the *same* as the old
value, not if the new value is *different*.

<rdar://problem/16712205>

llvm-svn: 207148
2014-04-24 21:43:04 +00:00
Saleem Abdulrasool 324a103619 sweep up -Wformat warnings from gcc
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
2014-04-04 04:06:10 +00:00
Sean Callanan c4ca2c1d60 Made the Materializer not write back variables
if they didn't change, just like it does for
registers.  This makes life easier for kernel
debugging and any other situation where values
are read-only.

<rdar://problem/16367795>

llvm-svn: 204764
2014-03-25 22:30:19 +00:00
Sean Callanan 866e91c9d4 Better error reporting when a variable can't be
read during materialization.  First of all, report
if we can't read the data for some reason.  Second,
consult the ValueObject's error and report that if
there's some problem.

<rdar://problem/16074201>

llvm-svn: 202552
2014-02-28 22:27:53 +00:00
Sean Callanan 22ac610c4f Harden the Materializer logic against types that
don't know their bit alignment.

llvm-svn: 199173
2014-01-14 01:14:40 +00:00
Sean Callanan 65b320f783 Fixed a bug where the expression parser doesn't
materialize a variable in a register correctly
if the variable is a pointer.  This fixes a
regression introduced by my commit of Oct. 22nd
(r193191).

llvm-svn: 198718
2014-01-07 23:15:26 +00:00
Greg Clayton 3ebae49748 Fixed printf warnings. The GetByteSize() results return uint64_t values, not size_t values.
llvm-svn: 194587
2013-11-13 18:01:16 +00:00
Ed Maste d23dcbfb53 Increase log detail for size mismatch in EntityVariable::Materialize
llvm-svn: 194413
2013-11-11 19:40:51 +00:00
Jason Molenda b57e4a1bc6 Roll back the changes I made in r193907 which created a new Frame
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
2013-11-04 09:33:30 +00:00
Jason Molenda f23bf7432c Add a new base class, Frame. It is a pure virtual function which
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
2013-11-02 02:23:02 +00:00
Sean Callanan 13b4ef2dba Simplified the code that materializes a variable,
obviating the need to create a new ValueObject.

llvm-svn: 193191
2013-10-22 20:01:17 +00:00
Sean Callanan 3e68903e58 Fixed a bug in the Materializer where we sent the
wrong information to ValueObjectConstResult.

<rdar://problem/15101795>

llvm-svn: 192264
2013-10-09 02:04:57 +00:00
Sean Callanan d2a507a6e6 Modified the expression parser to only try to
write to registers if they were modified in the
expression.  This eliminates spurious errors if
the register can't be written to but the
expression didn't write to it anyway.

Also improved error handling for the materializer
to make "couldn't materialize struct" errors more
informative.

<rdar://problem/14322579>

llvm-svn: 186228
2013-07-12 23:35:21 +00:00
Greg Clayton 57ee306789 Huge change to clean up types.
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
2013-07-11 22:46:58 +00:00
Sean Callanan a4e8105bfd Fixed a problem with materialization and
dematerialization of registers that caused
conditional breakpoint expressions not to
work properly.  Also added a testcase.

<rdar://problem/14129252>

llvm-svn: 184451
2013-06-20 18:42:16 +00:00
Matt Kopec ef14371d3f Fix various build warnings.
llvm-svn: 183140
2013-06-03 18:00:07 +00:00
Sean Callanan fbf5c682cb Fixed a bug where persistent variables did not
live as long as they needed to.  This led to
equality tests involving persistent variables
often failing or succeeding when they had no
business doing so.

To do this, I introduced the ability for a
memory allocation to "leak" - that is, to
persist in the process beyond the lifetime of
the expression.  Hand-declared persistent
variables do this now.

<rdar://problem/13956311>

llvm-svn: 182528
2013-05-22 22:49:06 +00:00
Greg Clayton 9e9f219a8c <rdar://problem/13893094>
Show variables that were in the debug info but optimized out. Also display a good error message when one of these variables get used in an expression.

llvm-svn: 182066
2013-05-17 00:55:28 +00:00
Sean Callanan df56540a58 Performance optimizations to ClangUserExpression,
mostly related to management of the stack frame
for the interpreter.

  - First, if the expression can be interpreted,
    allocate the stack frame in the target process
    (to make sure pointers are valid) but only
    read/write to the copy in the host's memory.

  - Second, keep the memory allocations for the
    stack frame and the materialized struct as
    member variables of ClangUserExpression.  This
    avoids memory allocations and deallocations
    each time the expression runs.

<rdar://problem/13043685>

llvm-svn: 180664
2013-04-27 02:19:33 +00:00
Sean Callanan 2afbf4440c Fixed the expression parser's handling of result
and persistent variables so that they are not
treated as remaining in the target process (i.e.,
having live data) when the process does not allow
persistent allocations (e.g., when there is no
process or in the case of kernel core files).

llvm-svn: 179919
2013-04-20 02:40:45 +00:00
Sean Callanan ed185ab5c7 Fixed two problems when reading constant/register
variables in the ValueObject code:

  - Report an error if the variable does not have
    a valid address.

  - Return the contents of the data to GetData(),
    even if the value is constant.

<rdar://problem/13690855>

llvm-svn: 179876
2013-04-19 19:47:32 +00:00
Sean Callanan 1582ee6840 This commit changes the way LLDB executes user
expressions.  

Previously, ClangUserExpression assumed that if
there was a constant result for an expression 
then it could be determined during parsing.  In
particular, the IRInterpreter ran while parser
state (in particular, ClangExpressionDeclMap) 
was present.  This approach is flawed, because
the IRInterpreter actually is capable of using
external variables, and hence the result might
be different each run.  Until now, we papered
over this flaw by re-parsing the expression each
time we ran it.

I have rewritten the IRInterpreter to be 
completely independent of the ClangExpressionDeclMap.
Instead of special-casing external variable lookup,
which ties the IRInterpreter closely to LLDB,
we now interpret the exact same IR that the JIT
would see.  This IR assumes that materialization
has occurred; hence the recent implementation of the
Materializer, which does not require parser state
(in the form of ClangExpressionDeclMap) to be 
present.

Materialization, interpretation, and dematerialization
are now all independent of parsing.  This means that
in theory we can parse expressions once and run them
many times.  I have three outstanding tasks before
shutting this down:

    - First, I will ensure that all of this works with
      core files.  Core files have a Process but do not
      allow allocating memory, which currently confuses
      materialization.

    - Second, I will make expression breakpoint 
      conditions remember their ClangUserExpression and
      re-use it.

    - Third, I will tear out all the redundant code
      (for example, materialization logic in
      ClangExpressionDeclMap) that is no longer used.

While implementing this fix, I also found a bug in
IRForTarget's handling of floating-point constants.  
This should be fixed.

llvm-svn: 179801
2013-04-18 22:06:33 +00:00
Sean Callanan 14b1bae5ee Flipped the big switch: LLDB now uses the new
Materializer for all expressions that need to
run in the target.  This includes the following
changes:

- Removed a bunch of (de-)materialization code
  from ClangExpressionDeclMap and assumed the
  presence of a Materializer where we previously
  had a fallback.

- Ensured that an IRMemoryMap is passed into
  ClangExpressionDeclMap::Materialize().

- Fixed object ownership on LLVMContext; it is
  now owned by the IRExecutionUnit, since the
  Module and the ExecutionEngine both depend on
  its existence.

- Fixed a few bugs in IRMemoryMap and the
  Materializer that showed up during testing.

llvm-svn: 179649
2013-04-16 23:25:35 +00:00