a function in the inferior.

llvm-svn: 147592

llvm-svn: 147590

result variable on a "finish" statement.  The
ownership of the result value was not being properly
assigned to the newly-created persistent result
variable; now it is.

llvm-svn: 147587

Be better at detecting when DWARF changes and handle this more
gracefully than asserting and exiting.

Also fixed up a bunch of system calls that weren't properly checking
for EINTR.

llvm-svn: 147559

resolves values in registers.

llvm-svn: 147551

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

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: 147209

the name for an external variable in the IR.

llvm-svn: 147178

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

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

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

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

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

Add NULL checks for SBDebugger APIs.

llvm-svn: 146917

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

Add NULL checks for SBCommandReturnObject.AppendMessage().

llvm-svn: 146911

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

Add NULL checks for SBCommandInterpreter APIs.

llvm-svn: 146909

<rdar://problem/10596340>

llvm-svn: 146902

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

Add NULL checks for SBModule and SBSection APIs.

llvm-svn: 146899

"id" from being found by the parser as an
externally-defined type.  Before, "id" would
sometimes make it through if it was defined in
a namespace, but this sometimes caused
confusion, for example when it conflicted with
std::locale::id.

llvm-svn: 146891

SBThread::GetStopReasonDataCount/GetStopReasonDataAtIndex() need to handle eStopReasonWatchpoint.

llvm-svn: 146812

as part of the thread format output.
Currently this is only done for the ThreadPlanStepOut.
Add a convenience API ABI::GetReturnValueObject.
Change the ValueObject::EvaluationPoint to BE an ExecutionContextScope, rather than
trying to hand out one of its subsidiary object's pointers.  That way this will always
be good.

llvm-svn: 146806

which have the dwarf DIE tag (DW_TAG_XXX enum) and TypeFlags for each type.

llvm-svn: 146802

llvm-svn: 146798

valobj.AddressOf() returns None when an address is expected in a SyntheticChildrenProvider

Patch from Enrico Granata:

The problem was that the frozen object created by the expression parser was a copy of the contents of the StgClosure, rather than a pointer to it. Thus, the expression parser was correctly computing the result of the arithmetic&cast operation along with its address, but only saving it in the live object. This meant that the frozen copy acted as an address-less variable, hence the problem.

The fix attached to this email lets the expression parser store the "live address" in the frozen copy of the address when the object is built without a valid address of its own.
Doing so, along with delegating ValueObjectConstResult to calculate its own address when necessary, solves the issue. I have also added a new test case to check for regressions in this area, and checked that existing test cases pass correctly.

llvm-svn: 146768

we handle Objective-C method calls.  Currently,
LLDB treats the result of an Objective-C method
as unknown if the type information doesn't have
the method's signature.  Now Clang can cast the
result to id if it isn't explicitly cast.

I also added a test case for this, as well as a
fix for a type import problem that this feature
exposed.

llvm-svn: 146756

handles.

llvm-svn: 146746