Fixed a case where the result of std::string's c_str() method was being called on a local variable and returned as a const char * incorrectly. We used to cache the thread names for threads in the current host process, but we shoudn't be caching that as the names can change over time, so now a std::string is returned from Host::GetThreadName().

llvm-svn: 176217

llvm-svn: 176210

llvm-svn: 176206

in the Process destructor.  Doing it there can be too late depending on what the internal state
and ProcessGDBRemote Async threads are doing.

<rdar://problem/13297536>

llvm-svn: 176203

binary to lldb already check that the UUID of that binary and the UUID of
the kernel binary in memory match.  Warn if they don't.
<rdar://problem/13184784> 

llvm-svn: 176160

Fixed an issue with clang 500's new way to represent static class variables where it emits a DW_TAG_member with a DW_AT_external(0x01) attribute and no DW_AT_data_member_location.

llvm-svn: 176140

llvm-svn: 176106

llvm-svn: 176071

SymbolFileDWARF code:

  - If a class is being uniqued to another copy of itself
    and the method lists don't match exactly, take a slow
    path and at least unique the methods that they have
    in common.

  - Sort name_to_die maps before querying them.  This
    would otherwise result in uniquing failures because
    looking up a name in a map that contains it would
    often fail.

  - Tolerate classes in other symbol files in the case
    of debugging with .o files rather than with a
    .dSYM.  We used to assume that the classes being
    uniqued were in the same symbol file, causing
    unpredictable results.

This will dramatically reduce the number of cases where
a function does not have a valid DeclContext.

<rdar://problem/12153915>

llvm-svn: 176067

llvm-svn: 176065

plugin.dynamic-loader.darwin-kernel.load-kexts setting, don't print
any messages about loading the kexts (which isn't being done) and
don't read the Mach-O headers out of memory (which can be slow and
they're not being used for anything at this point).

llvm-svn: 176064

Set the exception breakpoints more efficiently by specifying two module basenames as module filters for Apple vendor targets.

llvm-svn: 176063

llvm-svn: 176041

StackFrame assumes m_sc is additive, but m_sc can lose its target. So now the SymbolContext::Clear() method takes a bool that indicates if the target should be cleared. Modified all existing code to properly set the bool argument.

llvm-svn: 175953

in the gdb-remote Process plugin files.

llvm-svn: 175947

<rdar://problem/13270229>

llvm-svn: 175927

Fixed an issue where if we got a 'A' async packet back from debugserver, we would resend the last continue command. We now correctly identify the packet as async (just like the 'O' stdout async packet) and we don't resend the continue command.

llvm-svn: 175924

The thread plans run before the event is broadcast, so they should be calling ShouldStopSynchronous on any Stop Info's
they want to check.  The full ShouldStop should only be called on the public side of the event system.

llvm-svn: 175922

llvm-svn: 175915

This was preventing us from providing a summary for the result of std::string.c_str() with libc++

llvm-svn: 175841

The notion of Crossref command has long been forgotten, and there is nothing using CommandObjectCrossref in the current LLDB codebase
However, this was causing a conflict with process plugins and command aliases ending up in an infinite loop under situations such as:
(lldb) command alias monitor process plugin packet monitor
(lldb) process att -n Calendar
Process 28709 stopped
Executable module set to "/Applications/Calendar.app/Contents/MacOS/Calendar".
Architecture set to: x86_64-apple-macosx.
(lldb) command alias monitor process plugin packet monitor

This fixes the loop (and consequent crash) by disposing of Crossref commands and related code

llvm-svn: 175831

llvm-svn: 175829

On x86-64 platforms, the small code model assumes that code will be loaded below the 2GB boundary.  With the static relocation model, the fact that the expression code is initially loaded (in the LLDB debugger address space) above that boundary causes problems.  Switching to the JITDefault code model causes the large code model to be used for 64-bit targets and small code model of 32-bit targets.

llvm-svn: 175828

<rdar://problem/13254824>

llvm-svn: 175806

llvm-svn: 175798

llvm-svn: 175797

- generate-vers.pl has to be called by cmake to generate the version number
- parallel builds not yet supported; dependency on clang must be explicitly specified

Tested on Linux.
- Building on Mac will require code-signing logic to be implemented.
- Building on Windows will require OS-detection logic and some selective directory inclusion

Thanks to Carlo Kok (who originally prepared these CMakefiles for Windows) and Ben Langmuir
who ported them to Linux!

llvm-svn: 175795

of its own target.

<rdar://problem/13121412>

llvm-svn: 175794

llvm-svn: 175792

Adding data formatters for iterators for std::map and std::vector (both libc++ and libstdcpp)
This does not include reverse iterators since they are both trickier (due to requirements the standard imposes on them) and much less useful

llvm-svn: 175787

(lldb) frame variable
without first launching the inferior, you get:
error: invalid frame

this is misleading and should probably hint that there is no process. Adding this flag makes sure that we get:
error: invalid process

The difference between eFlagRequiresProcess and eFlagProcessMustBeLaunched is an open question.

llvm-svn: 175702

work on i386.  Now we let the JIT emit SSE/SSE2
instructions on i386.

<rdar://problem/13240476>

llvm-svn: 175700

llvm-svn: 175691

llvm-svn: 175671

return methods.

rdar://problem/13238168

llvm-svn: 175662

<rdar://problem/13093321>

llvm-svn: 175573

Be more user-friendly about not having scripting enabled:
a) if Python was built-out then tell people about it explicitly
b) if we are told to use none as a scripting language, then tell people about that too

This should limit the cases where the semi-cryptic error message "there is no embedded script interpreter in this mode." actually shows

llvm-svn: 175570

ValueObjectSynthetic could be wrapping a ValueObjectDynamic. In that case, we want to report that the ValueObject is dynamic since synthetic values are supposed to be just their parent with different children

llvm-svn: 175563

llvm-svn: 175546

Add i386 register support for the x86_64 RegisterContext plugin. This allows debugging a 32-bit inferior on 64-bit lldb/host.

llvm-svn: 175543