resolves values in registers.

llvm-svn: 147551

breakpoints.

llvm-svn: 147549

to include -- in sample command lines.  Now LLDB
prints

  expression [-f <format>] -- <expr>

instead of

  expression [-f <format>] <expr>

and also adds a new example line:

  expression <expr>

to show that in the absense of arguments the --
can be ommitted.

llvm-svn: 147540

eFormatCString is specified, I have made
DataExtractor::Dump properly escape the string.
This prevents LLDB from printing characters
that confuse terminals.

llvm-svn: 147536

Watch for empty symbol tables by doing a lot more error checking on
all mach-o symbol table load command values and data that is obtained.
This avoids a crash that was happening when there was no string table.

llvm-svn: 147358

Fixed a crasher that can occur when parsing invalid DWARF.

llvm-svn: 147350

Fixed an issue where our new accelerator tables could cause a crash
when we got a full 32 bit hash match, yet a C string mismatch.

We had a member variable in DWARFMappedHash::Prologue named 
"min_hash_data_byte_size" the would compute the byte size of HashData
so we could skip hash data efficiently. It started out with a byte size
value of 4. When we read the table in from disk, we would clear the
atom array and read it from disk, and the byte size would still be set
to 4. We would then, as we read each atom from disk, increment this count. 
So the byte size of the HashData was off, which means when we get a lookup
whose 32 bit hash does matches, but the C string does NOT match (which is
very very rare), then we try and skip the data for that hash and we would
add an incorrect offset and get off in our parsing of the hash data and 
cause this crash. 

To fix this I added a few safeguards:
1 - I now correctly clear the hash data size when we reset the atom array using the new DWARFMappedHash::Prologue::ClearAtoms() function. 
2 - I now correctly always let the AppendAtom() calculate the byte size of the hash (before we were doing things manually some times, which was correct, but not good)
3 - I also track if the size of each HashData is a fixed byte size or not, and "do the right thing" when we need to skip the data.
4 - If we do get off in the weeds, then I make sure to return an error and stop any further parsing from happening. 

llvm-svn: 147334

Fixed SBValue::GetValueAsUnsigned() and SBValue::GetValueAsSigned() calls to
work for bitfields.

llvm-svn: 147332

llvm-svn: 147330

llvm-svn: 147325

vector that can be sized to fit.

llvm-svn: 147324

llvm-svn: 147214

LLDB (python bindings) Crashing in lldb::SBDebugger::DeleteTarget(lldb::SBTarget&)

Need to check the validity of (SBTarget&)target passed to SBDebugger::DeleteTarget()
before calling target->Destroy().

llvm-svn: 147213

llvm-svn: 147212

llvm-svn: 147209

llvm-svn: 147193

the name for an external variable in the IR.

llvm-svn: 147178

Decorate the two test cases in TestReturnValue.py as i386 only expectedFailure, aka @expectedFailurei386.

llvm-svn: 147177

llvm-svn: 147172

With some minor modification from me.

llvm-svn: 147160

Switch from GetReturnValue, which was hardly ever used, to GetReturnValueObject
which is much more convenient.
Return the "return value object" as a persistent variable if requested.

llvm-svn: 147157

llvm-svn: 147149

complete the result type, preventing crashes later.

llvm-svn: 147107

parser has hitherto been an implementation waiting
for a use.  I have now tied the '-o' option for
the expression command -- which indicates that the
result is an Objective-C object and needs to be
printed -- to the ExpressionParser, which
communicates the desired type to Clang.

Now, if the result of an expression is determined
by an Objective-C method call for which there is
no type information, that result is implicitly
cast to id if and only if the -o option is passed
to the expression command.  (Otherwise if there
is no explicit cast Clang will issue an error.
This behavior is identical to what happened before
r146756.)

Also added a testcase for -o enabled and disabled.

llvm-svn: 147099

Xcode workspace that aren't actually desirable.
Reverted.

llvm-svn: 147097

llvm-svn: 147072

llvm-svn: 147061

llvm-svn: 147033

with incomplete definition data were being converted.
Now Clang attempts to complete RecordDecls before
converting them, avoiding a nasty crash.

llvm-svn: 147029

types that have been imported multiple times.

The discussion below uses this diagram:

ASTContext     A      B      C
Decl           Da     Db     Dc
ASTImporter    \-Iab-/\-Iac-/
               \-----Iac----/

When a Decl D is imported from ASTContext A to
ASTContext B, the ASTImporter Iab records the
pair <Da, Db> in a DenseMap.  That way, if Iab
ever encounters Da again (for example, as the
DeclContext for another Decl), it can use the
imported version.  This is not an optimization,
it is critical: if I import the field "st_dev"
as part of importing "struct stat," the field
must have DeclContext equal to the parent
structure or we end up with multiple different
Decls containing different parts of "struct
stat."  "struct stat" is imported once and
recorded in the DenseMap; then the ASTImporter
finds that same version when looking for the
DeclContext of "st_dev."

The bug arises when Db is imported into another
ASTContext C and ASTContext B goes away.  This
often occurs when LLDB produces result variables
for expressions.  Ibc is aware of the transport
of Db to Dc, but a brand new ASTImporter, Iac,
is responsible for completing Dc from its source
upon request.  That ASTImporter has no mappings,
so it will produce a clone of Dc when attempting
to import its children.  That means that type
completion operations on Dc will fail.

The solution is to create Iac as soon as Ibc
imports D from B to C, and inform Iac of the
mapping between Da and Dc.  This allows type
completion to happen correctly.

llvm-svn: 147016

llvm-svn: 146978

llvm-svn: 146957

llvm-svn: 146956

rdar://problem/10577182
Audit lldb API impl for places where we need to perform a NULL check

Add a NULL check for SBValue.CreateValueFromExpression().

llvm-svn: 146954

rdar://problem/10577182
Audit lldb API impl for places where we need to perform a NULL check

Add a NULL check for SBTarget.AttachToProcessWithName() so it will not hang.

llvm-svn: 146948

llvm-svn: 146936

llvm-svn: 146935

rdar://problem/10577182
Audit lldb API impl for places where we need to perform a NULL check

Add NULL checks for SBStream APIs.

llvm-svn: 146934

llvm-svn: 146930

llvm-svn: 146924