These fail due to:
error: Expression can't be run, because there is no JIT compiled function

llvm-svn: 187072

Added comment to llvm.org/pr14600 that it fails on FreeBSD in the same way
as Linux.

llvm-svn: 187070

llvm-svn: 187069

Fixed a crasher where if you accidentally specify a size that is too large when reading memory, LLDB would crash.

llvm-svn: 187060

This allows compilation of the test case with GCC 4.8.

llvm-svn: 187057

llvm-svn: 187045

llvm-svn: 187043

Also accomodate struct padding based on arch, for later i386 work.

llvm-svn: 187040

llvm-svn: 187037

llvm-svn: 187036

llvm-svn: 187035

llvm-svn: 186992

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

llvm-svn: 186979

This change removes the final instances of compile-time #ifdef magic
from the elf core plugin.  Also rename the classes to ELFLinux... as
they're specific to Linux.

llvm-svn: 186977

This avoids the use of the ELFPrStatus class, which returns to being
used only for Linux.

llvm-svn: 186976

Extracting thread data at parse time simplifies multi-platform support.
This change adds FreeBSD thread names and auxv info.

Thanks to Samuel Jacob for review, testing, and improvements.

llvm-svn: 186975

ELF notes contain a 'name' field, which specifies a vendor who defines
the format of the note.  Examples are 'FreeBSD' or 'GNU', or it may be
empty for generic notes.

Add a case for FreeBSD-specific notes, leaving Linux and GNU notes,
other vendor-specific notes, and generic notes to be handled by the
existing code for now.

Thanks to Samuel Jacob for reviewing and suggesting improvements.

llvm-svn: 186973

-C usually specifies a script to prepopulate the CMake cache. In this case no
script is specified, so CMake appears to just ignore it. So don't mention it
in the first place - it's not desired anyways.

Reviewed by: Daniel Malea

llvm-svn: 186964

because a synthetic symbol hasn't been provided for stripped function symbols.

llvm-svn: 186959

Reviewed by: Daniel Malea

llvm-svn: 186958

caused by a CFStringRef going out of scope.

llvm-svn: 186912

thumb mode.
<rdar://problem/14107444>, <rdar://problem/14107405>

llvm-svn: 186881

llvm-svn: 186871

Instantiate RegisterContextCore... based on getOS() instead of with
compile-time #ifdef-ery.

The assert()s here are unfortunate, but better than crashing with no
explanation.  (This would previously happen for an unsupported
architecture, anyhow.)

We should add an equivalent OS and architecture test to
ProcessElfCore::DoLoadCore() and cleanly report the error to the user.

llvm-svn: 186865

On FreeBSD I see that Arch, Vendor, OS, and Environment are unchanged
after this call (for x86_64, at least), and core debugging works without
it.

If we need to restore it we should be able to switch on
arch.GetTriple.getOS() instead of a compile-time #ifdef.

Thanks to Daniel Malea for testing on Linux.

llvm-svn: 186862

llvm-svn: 186822

llvm-svn: 186717

llvm-svn: 186712

Your mileage may vary depending on the gcc and stl versions in use (see llvm.org/pr15301).

llvm-svn: 186706

llvm-svn: 186699

llvm-svn: 186698

llvm-svn: 186697

llvm-svn: 186693

RegisterContextLLDB::SavedLocationForRegister to cache the pc and
sp register numbers -- if lldb is debugging multiple Targets of
different architectures, this will be incorrect.  If these were
to be cached anywhere, it would have to be up in the Target.

llvm-svn: 186651

rdar://problem/14488761

llvm-svn: 186646

On FreeBSD we have only one NT_PRPSINFO in a core file, regardless of the
number of threads.  Consider a new thread to start whenever we see another
instance of either NT_PRPSINFO or NT_PRSTATUS.

Thanks to Samuel Jacob for testing this patch on Linux cores.

llvm-svn: 186633

plan providers from a "ThreadPlan *" to a "lldb::ThreadPlanSP".  That was needed to fix
a bug where the ThreadPlanStepInRange wasn't checking with its sub-plans to make sure they
succeed before trying to proceed further.  If the sub-plan failed and as a result didn't make
any progress, you could end up retrying the same failing algorithm in an infinite loop.

<rdar://problem/14043602>

llvm-svn: 186618

<rdar://problem/14460024>

llvm-svn: 186597

llvm-svn: 186596