to assume it's of pointer size.

llvm-svn: 147906

to fix the issues we run into on darwin even though the docs don't
seems to say it will.

llvm-svn: 147835

when you already know that the address is contained in a bona fide function.  This can be a 
slow call.

llvm-svn: 147829

in the module when dumping the information in addition to all info that we
were previously showing.

llvm-svn: 147815

takes to open and index BSD archives.

llvm-svn: 147813

it was checked in as:
 virtual bool ABI::FixCodeAddress (lldb::addr_t pc);

when it should have been:

virtual lldb::addr_t ABI::FixCodeAddress (lldb::addr_t pc);


 

llvm-svn: 147790

Fixed an ARM backtracing issue where if the previous frame was a thumb
function and it was a tail call so that the current frame returned to
an address that would fall into the next function, we would use the
next function as the basis for how we unwound the previous frame's
registers and of course get things wrong. We now fix the PC code
address using the current ABI plug-in, and the ARM ABI plug-in has
been modified to correctly fix the code address. So when we do the
symbol context lookup, instead of taking an address like 0x1001 and
decrementing 1, and looking up the symbol context for a frame, we
now correctly fix 0x1001 to 0x1000, then decrement that by 1 to
get the correct symbol context.

I added a bunch more logging to "log enable lldb uwnind" to help
us in the future. We now log the PC, FP and SP (if they are available),
and we also dump the "active_row" that we find for unwinding a frame.

llvm-svn: 147747

Fixed the default ARM regiter set to be able to refer to "r7" as "fp" for the apple debugserver.

llvm-svn: 147746

The previous approach to controlling the recursion was doing it from
outside the function which is not reliable. Now it is being done inside
the function. This might not solve all of the crashes that we were seeing
since there are other functions that clear the bit that indicates that
the summary is in the process of being generated, but it might solve some.

llvm-svn: 147741

Fixed dynamic types for objective C to not try and make everything dynamic including base classes.

llvm-svn: 147722

class instead of requiring a live process in order to be able to create useful
SBData objects.

llvm-svn: 147702

parser was creating malformed resuls.  When the
location of a variable is computed by reading a
register and adding an offset, we shouldn't say
that the variable's value is located in that
register.  This was confusing the expression
parser when trying to read a variable captured
by a block.

llvm-svn: 147668

Fixed a crasher when trying to load an expression prefix file:

% touch /tmp/carp.txt
% xcrun lldb
(lldb) settings set target.expr-prefix /tmp/carp.txt
Segmentation fault

llvm-svn: 147646

Fixed an issue where the python interpreter could deadlock LLDB.

llvm-svn: 147640

Allow creating SBData values from arrays or primitives in Python

Patch submitted by Enrico Granata.

llvm-svn: 147639

Removed an extra call to close that was causing problems and also
now use the Host::File class to open the file.

llvm-svn: 147638

lldb::SBValue::AddressOf does not work on dereferenced registers in synthetic children provider

Patch submitted by Enrico Granata.

llvm-svn: 147637

emit fully qualified names, so now we make sure the DW_TAG values match and
still lookup using the basename.

llvm-svn: 147634

comma at end of enumerator list

llvm-svn: 147633

llvm-svn: 147629

llvm-svn: 147627

This patch combines common code from Linux and FreeBSD into
a new POSIX platform.  It also contains fixes for 64bit FreeBSD.

The patch is based on changes by Mark Peek <mp@FreeBSD.org> and
"K. Macy" <kmacy@freebsd.org> in their github repo located at
https://github.com/fbsd/lldb.

llvm-svn: 147613

a new POSIX platform.  It also contains fixes for 64bit FreeBSD.

The patch is based on changes by Mark Peek <mp@FreeBSD.org> and
"K. Macy" <kmacy@freebsd.org> in their github repo located at
https://github.com/fbsd/lldb.

llvm-svn: 147609

so that we don't have "fprintf (stderr, ...)" calls sprinkled everywhere.
Changed all needed locations over to using this.

For non-darwin, we log to stderr only. On darwin, we log to stderr _and_
to ASL (Apple System Log facility). This will allow GUI apps to have a place
for these error and warning messages to go, and also allows the command line
apps to log directly to the terminal.

llvm-svn: 147596

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