llvm-svn: 190027

llvm-svn: 190026

llvm-svn: 190025

have a certain name, not just the first.  This
is useful if a class method and an instance
method have the same name.

<rdar://problem/14872081>

llvm-svn: 190008

Testing shows it works for at least trivial cases, while the
USE_STANDARD_JIT case does not even work for those.  Thus, don't define
USE_STANDARD_JIT on FreeBSD.

I've left the #if block choosing the appropriate #include in case it's
useful for testing.

llvm-svn: 189611

- factorize unistd.h and stdbool.h in lldb-types.h.
- Add <functional> and <string> where required.

llvm-svn: 189477

llvm-svn: 189107

live beyont parsing.  This is important because
all the ClangASTImporter::Minions for a parser's
ASTContext are cleared when ClangExpressionDeclMap
is deleted.

This resolves many hard-to-reproduce crashes,
especially ones involving breakpoint conditions.

<rdar://problem/14775391>

llvm-svn: 189080

llvm-svn: 187900

llvm-svn: 187822

the extra check introduces 22 new test failures with the LLDB clang buildbot.

Note that the unhandled DWARF_OP codes in DWARFExpression::Evaluate don't cause test failures if the check is ignored.

llvm-svn: 187480

list have a shared pointer back to their DisassemblerLLVMC.  This checkin force clears the InstructionList
in all the places we use the DisassemblerSP to stop the leaking for now.  I'll go back and fix this
for real when I have time to do so.

<rdar://problem/14581918>

llvm-svn: 187473

- better than failing silently next time the DWARF standard introduces new opcodes!

llvm-svn: 187449

in LLDB that load the canonical frame address rather than a location list.

- Handles the simple case where a CFA can be pulled from the current stack frame.
- Fixes more than one hundred failing tests with gcc 4.8!

TODO: Use UnwindPlan::GetRowForFunctionOffset if the DWARFExpression needs
to be evaluated in a context analogous to a virtual unwind (perhaps using RegisterContextLLDB).

- Also adds some comments to DWARFCallFrameInfo whenever I got confused.

llvm-svn: 187361

If we are replacing a function with the nobuiltin attribute, it may be called
with the builtin attribute on call sites. Remove any such attributes since it's
illegal to have a builtin call to something other than a nobuiltin function.

This fixes the current buildbot breakage (where LLDB crashes on
"expression new foo(42)").

llvm-svn: 186990

delete a constant after we replaced it with a
dynamically-computed value.  Also ensured that we
replace all users of the constant if there are
multiple ones.  Added a testcase.

<rdar://problem/14379043>

llvm-svn: 186363

creating a persistent variable, rather than making
a (potentially expensive) lookup by name.

<rdar://problem/14337653>

llvm-svn: 186337

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

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

Import the builtin type prefix before we import the user expression prefix so that the user expression prefix can use the uint, int, size_t, and other types without having to define them.

llvm-svn: 185488

llvm-svn: 185233

been suitable for preparing a single IR function
for operation in the target.  However, using blocks
and lambdas creates other IR functions that also
need to be processed.

I have audited IRForTarget to make it process
multiple functions.  Where IRForTarget would add
new instructions at the beginning of the main
expression function, it now adds them on-demand
in the function where they are needed.  This is
enabled by a system of FunctionValueCaches, which
invoke a lambda to create or derive the values as
needed, or report the result of that lambda if it
has already been called for the given function.

<rdar://problem/14180236>

llvm-svn: 185224

Default parameters are evil and should not be used. Case and point this checkin that fixes implicit conversions that were happening.

llvm-svn: 185217

the time when the IRInterpreter ran inside
IRForTarget.

llvm-svn: 185088

has more than one function with a body.  This
prevents declarations e.g. of blocks from being
passed to the IRInterpreter; they must pass
through to the JIT.

<rdar://problem/14180236>

llvm-svn: 185057

correctly.  We have been getting lucky since most
expressions generate only one section (or the first
code section contains all the code), but sometimes
it actually matters.

<rdar://problem/14180236>

llvm-svn: 185054

bother checking if a region is safe to use.  In
cases where regions need to be synthesized rather
than properly allocated, the memory reads required
to determine whether the area is used are

- insufficient, because intermediate locations
  could be in use, and

- unsafe, because on some platforms reading from
  memory can trigger events.

All this only makes a difference on platforms
where memory allocation in the target is impossible.
Behavior on platforms where it is possible should
stay the same.

<rdar://problem/14023970>

llvm-svn: 185046

llvm-svn: 184954

llvm-svn: 184948

the target of a typedef when asked for a typedef.

llvm-svn: 184886

dematerialization of registers that caused
conditional breakpoint expressions not to
work properly.  Also added a testcase.

<rdar://problem/14129252>

llvm-svn: 184451

llvm-svn: 184333

caused the IR interpreter not to work if the
process had finished running.

<rdar://problem/14124301>

llvm-svn: 184125

llvm-svn: 183991

llvm-svn: 183946

reading non-standard value sizes.

<rdar://problem/14081292>

llvm-svn: 183448

 - Implemented the SExt instruction, and

 - eliminated redundant codepaths for constant
   handling.

Added test cases.

<rdar://problem/13244258>
<rdar://problem/13955820>

llvm-svn: 183344

llvm-svn: 183250

- ConstantDataArray is not a valid MDNode operand
- encode function-name strings in metadata by wrapping in an MDString instead

- should resolve reported by http://llvm-jenkins.debian.net/job/llvm-toolchain-quantal-binaries/architecture=amd64,distribution=quantal/173/

llvm-svn: 183153