whether a given address is in an executable region of memory or
not.  I haven't written the lldb side that will use this packet it
hasn't been tested yet but it's a simple enough bit of code.

I want to have this feature available for the unwinder code.  When
we're stopped at an address with no valid symbol context, there are
a number of questions I'd like to ask --

  is the current pc value in an executable region (e.g. did they
  jump to unallocated/unexecutable memory?  we know how to unwind
  from here if so.)

  Is the stack pointer or the frame pointer the correct register
  to use to find the caller's saved pc value?

Once we're past the first frame we can trust things like eh_frame
and ABI unwind schemes but the first frame is challenging and having
a way to check potential addresses to see if they're executable or
not would help narrow down the possibilities a lot.

llvm-svn: 144074

doesn't handle bitfields in eFormatChar's correctly, only eFormatUnsigned.
Fix DataExtractor::Dump to dump the bitfield eFormatChars correctly.

llvm-svn: 144069

Do a better job of detecting when a breakpoint command has set the target running again (except you have to ignore
cases where the breakpoint runs expressions, those don't count as really "running again").

llvm-svn: 144064

be in the target. All of the environment, args, stdin/out/err files, etc have
all been moved. Also re-enabled the ability to launch a process in a separate
terminal on MacOSX.

llvm-svn: 144061

Moved the fixed ScriptSummaryFormat forward declaration into the #ifndef LLDB_DISABLE_PYTHON so it doesn't show up in builds where it is supposed to be disabled.

llvm-svn: 144045

which will in the future allow expressions to be
compiled as C, C++, and Objective-C instead of the
current default Objective-C++.  This feature requires
some additional support from Clang -- specifically, it
requires reference types in the parser regardless of
language -- so it is not yet exposed to the user.

llvm-svn: 144042

imported variables.

llvm-svn: 144041

llvm-svn: 144040

Fix the test suite failure.  The particular line in the test case was there since the initial version
dated 2010-21-15.  The test started failure recently probably due to work done on the command parsing.
Anyway, the specific test sequence is invalid and is fixed now.

llvm-svn: 144039

 a) adds a new --synchronicity (-s) setting for "command script add" that allows the user to decide if scripted commands should run synchronously or asynchronously (which can make a difference in how events are handled)
 b) clears up several error messages
 c) adds a new --allow-reload (-r) setting for "command script import" that allows the user to reload a module even if it has already been imported before
 d) allows filename completion for "command script import" (much like what happens for "target create")
 e) prevents "command script add" from replacing built-in commands with scripted commands
 f) changes AddUserCommand() to take an std::string instead of a const char* (for performance reasons)
plus, it fixes an issue in "type summary add" command handling which caused several test suite errors

llvm-svn: 144035

llvm-svn: 144032

in "/System/Library/PrivateFrameworks", and also have "lldb" in the Xcode.app
and the LLDB.framework in Xcode.app as well.

llvm-svn: 144030

llvm-svn: 143774

llvm-svn: 143773

Joel Dillon that fixed 64 debugging for Linux.

I also added a patch to fix up the ProcessLinux::DoLaunch() to be up to date.
I wasn't able to verify it compiles, but it should b really close.

llvm-svn: 143772

crashes.

llvm-svn: 143756

C++ vtables, fixing a record layout problem in the
expression parser.

Also fixed various problems with the generation 
and unpacking of llvm.zip given our new better
handling of multiple architectures in the LLVM
build.

(And added a log message that will hopefully catch
record layout problems in the future.)

llvm-svn: 143741

we often nuke our "build" folder so we can do clean builds. This way if you
are building your own LLVM you won't have to rebuild LLVM when you do remove
your build folder. The new location for the LLVM build is:

lldb/llvm-build

llvm-svn: 143713

llvm-svn: 143710

llvm-svn: 143703

llvm-svn: 143694

llvm-svn: 143679

- If you download and build the sources in the Xcode project, x86_64 builds
  by default using the "llvm.zip" checkpointed LLVM.
- If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the
  Xcode project will download the right LLVM sources and build them from 
  scratch
- If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib"
  directory, we will use the sources you have placed in the LLDB directory.
  
Python can now be disabled for platforms that don't support it. 

Changed the way the libllvmclang.a files get used. They now all get built into
arch specific directories and never get merged into universal binaries as this
was causing issues where you would have to go and delete the file if you wanted
to build an extra architecture slice.

llvm-svn: 143678

target is stopped in a C++ or Objective-C method
but the "self" pointer's valid range actually
doesn't cover the current location.  Before, that
was confusing Clang to the point where it crashed;
now, we sanity-check and fall back to pretending
we're in a C function if "self" or "this" isn't
available.

llvm-svn: 143676

Greps and returns the first svn log entry containing a line matching the regular
expression pattern passed as the only arg.

Example:

svn log -v | grep-svn-log.py '^   D.+why_are_you_missing.h$'

llvm-svn: 143671

have the correct value in the IRInterpreter.

llvm-svn: 143663

llvm-svn: 143659

on internal only (public API hasn't changed) to simplify the paramter list
to the launch calls down into just one argument. Also all of the argument,
envronment and stdio things are now handled in a much more centralized fashion.

llvm-svn: 143656

llvm-svn: 143613

IRInterpreter to get the value, not the location,
of references.  The location of a reference has
type T&&, which is meaningless to Clang.

llvm-svn: 143592

llvm-svn: 143587

llvm-svn: 143586

llvm-svn: 143566

allows us to set __attribute__ ((used)) on expressions
that masquerade as methods.  When we are stopped in
classes in anonymous namespaces, this fix (and enabling
__attribute__ ((used)) on the method) will allow
expressions to run.

llvm-svn: 143560

Fixed an issue where the DWARF might mention that a class has a constructor
(default, copy or move), destructor, or an assignment operator (copy or move)
and it might not have an actual implementation in your code. Then you try and
use this struct or class in an expression and the JIT would ask for the 
address of these methods that were in the declaration, yet there are none.
We now "do the right thing" for trivial ctors, dtors and assignment operators
by telling the methods that they are are defaulted and trivial, and clang will
then just do all of the work with builtins!

llvm-svn: 143528

generated special member functions (constructors,
destructors, etc.) for classes that don't really have
them.  We needed to mark these as artificial to reflect
the debug information; this bug does that for
constructors and destructors.

The "etc." case (certain assignment operators, mostly)
remains to be fixed.

llvm-svn: 143526

correctly, and added a testcase to check that it works.

The main problem here is that Objective-C class method
selectors are external references stored in a special
data structure in the LLVM IR module for an expression.
I just had to extract them and ensure that the real
class object locations were properly resolved.

llvm-svn: 143520

llvm-svn: 143476

    '::my_uint_t', 'anon_uint = 0'

from:

    '(my_uint_t) anon_uint = 0'

to make the test suite clean with ToT.

llvm-svn: 143474

method as __attribute__ ((used)) when adding it to a
class.  This functionality is useful when stopped in
anonymous namespaces: expressions attached to classes
in anonymous namespaces are typically elided by Clang's
CodeGen because they have no namespaces are intended
not to be externally visible.  __attribute__ ((used))
forces CodeGen to emit the function.

Right now, __attribute__ ((used)) causes the JIT not to
emit the function, so we're not enabling it until we
fix that.

llvm-svn: 143469