which incurs large overheads in terms of type
parsing and importing.

llvm-svn: 154885

Fixed the ability to load multiple __LINKEDIT segments at the same address for darwin shared cache entries. Now when registering the load address of a section, the DynamicLoader objects can specify if they should warn or not. This will fix the ability to load the nlist entries for shared libraries in the darwin shared caches when no on disk representation is available for a shared library.

llvm-svn: 154860

Added a new host function that allows us to run shell command and get the output from them along with the status and signal:

Error
Host::RunShellCommand (const char *command,
                       const char *working_dir,
                       int *status_ptr,
                       int *signo_ptr,
                       std::string *command_output_ptr,
                       uint32_t timeout_sec);

This will allow us to use this functionality in the host lldb_private::Platform, and also use it in our lldb-platform binary. It leverages the existing code in Host::LaunchProcess and ProcessLaunchInfo.

llvm-svn: 154730

checking for LLDB mutex validity are static so
that entries put in there actually persist between
calls to error_check_mutex.

llvm-svn: 154727

Hello everyone,
 
please find the attached patch for TOT and lldb-platform-work branch, which provides the following changes:
 - fixed a crash in the ProcessPOSIX constructor when an executable module object is not yet created.
 - added support for the multi instanciated FreeBSD platform objects (the local host and remote as example).
 - enabled the remote gdb plugin on FreeBSD.

llvm-svn: 154724

The API lock was getting dropped too soon in GetVariables.  GetValueObjectForFrameVariable could run the target (to get dynamic values) and that requires the target lock.

llvm-svn: 154711

llvm-svn: 154710

Also fixed up some logging.

llvm-svn: 154709

The run all threads timeout in RunThreadPlan should respect the user timeout, not be arbitrarily 10 seconds (which was too long anyway...)
Also added some logging to RunThreadPlan and made others more regular.

llvm-svn: 154708

Added the thread ID (tid) to each packet history item and the packet history now always dumps to a lldb_private::Stream.

Enable logging the packet history when registers fail to read due to not getting the sequence mutex if "--verbose" is enabled on the log channel for the "gdb-remote" log category.

This will help us track down some issues.

llvm-svn: 154704

Factor out a bunch of common code in the two ThreadPlanCallFunction constructors.  Also add a sanity check - try reading the frame, and if we fail bag out.

llvm-svn: 154698

Fixed an error where lldb would hang when writing memory near the end of the addres space due to an unsigned overflow.

llvm-svn: 154697

llvm-svn: 154683

ThreadPlanCallFunction's destructor wasn't calling DoTakedown, so if the that plan got discarded we weren't doing the takedown.

llvm-svn: 154681

The less locks there are, the better. I removed the thread ID mutex and now just shared the m_thread_list's mutex to make sure we don't deadlock due to lock inversion.

llvm-svn: 154652

llvm-svn: 154650

Added more complete error checking for mutexes only for "Debug" builds where we always check if a mutex is valid prior to doing stuff with it. We also track when mutexes are initialized and destroyed and keep these in sets that can very subsequent pthread_mutex_XXX API calls.

llvm-svn: 154637

the debug information individual Decls came from.

We've had a metadata infrastructure for a while,
which was intended to solve a problem we've since
dealt with in a different way.  (It was meant to
keep track of which definition of an Objective-C
class was the "true" definition, but we now find
it by searching the symbols for the class symbol.)
The metadata is attached to the ExternalASTSource,
which means it has a one-to-one correspondence with
AST contexts.

I've repurposed the metadata infrastructure to
hold the object file and DIE offset for the DWARF
information corresponding to a Decl.  There are
methods in ClangASTContext that get and set this
metadata, and the ClangASTImporter is capable of
tracking down the metadata for Decls that have been
copied out of the debug information into the
parser's AST context without using any additional
memory.

To see the metadata, you just have to enable the
expression log:
-
(lldb) log enable lldb expr
-
and watch the import messages.  The high 32 bits
of the metadata indicate the index of the object
file in its containing DWARFDebugMap; I have also
added a log which you can use to track that mapping:
-
(lldb) log enable dwarf map
-

This adds 64 bits per Decl, which in my testing
hasn't turned out to be very much (debugging Clang
produces around 6500 Decls in my tests).  To track
how much data is being consumed, I've also added a
global variable g_TotalSizeOfMetadata which tracks
the total number of Decls that have metadata in all
active AST contexts.

Right now this metadata is enormously useful for
tracking down bugs in the debug info parser.  In the
future I also want to use this information to provide
more intelligent error messages instead of printing
empty source lines wherever Clang refers to the
location where something is defined.

llvm-svn: 154634

Expose GetAddressClass() from both the SBAddress and SBInstruction so clients can tell the difference between ARM/Thumb opcodes when disassembling ARM.

llvm-svn: 154633

FunctionDecls into classes if it looked up a
method in a different DWARF context than the
one where it found the parent class's definition.

The symptom of this was, for a method A::B(),

1) LLDB finds A in context 1, creating a
   CXXRecordDecl for A and marking it as needing
   completion

2) LLDB looks up B in context 2, finds that its
   parent A already has a CXXRecordDecl, but can't
   find a CXXMethodDecl for B

3) Not finding a CXXMethodDecl for B, LLDB doesn't
   set the flag indicating that B was resolved

4) Because the flag wasn't set, LLDB's fallthrough
   code creates a FunctionDecl for B and sticks it
   in the DeclContext -- in this case, A.

5) Clang crashes on finding a FunctionDecl inside a
   CXXRecordDecl.

llvm-svn: 154627

Fixed an issue that happens in LLDB versions after SBFrame switched to using a lldb::ExecutionContextRefSP where we might segfault due to using a shared pointer with NULL in it. The SBFrame object should always have a valid lldb::ExecutionContextRefSP in it. The SBFrame::Clear() method was doing the wrong thing and is now fixed.

llvm-svn: 154614

Also fixed the ProcessLinux, ProcessPOSIX and ProcessFreeBSD to have the correct UpdateThreadList() prototype.

llvm-svn: 154603

for packet confirmation.  
Also added a bit more logging.
Also, unlock the writer end of the run lock in Process.cpp on our way out of the private state
thread so that the Process can shut down cleanly.

<rdar://problem/11228538>

llvm-svn: 154601

is non-NULL before asking for its name.

llvm-svn: 154593

llvm-svn: 154535

llvm-svn: 154503

Cleaned up the Mutex::Locker and the ReadWriteLock classes a bit.

Also cleaned up the GDBRemoteCommunication class to not have so many packet functions. Used the "NoLock" versions of send/receive packet functions when possible for a bit of performance.

llvm-svn: 154458

cover all possible condition codes.

llvm-svn: 154440

not consume slots in the persistent variable
store.

llvm-svn: 154416

	QListThreadsInStopReply
	
This GDB remote query command can enable added a "threads" key/value pair to all stop reply packets so that we always get a list of all threads in each stop reply packet. It increases performance if enabled (the reply to the "QListThreadsInStopReply" is "OK") by saving us from sending to command/reply pairs (the "qfThreadInfo" and "qsThreadInfo" packets), and also helps us keep the current process state up to date. 

llvm-svn: 154380

A general stability fix where we _always_ get the thread list immediately after we get the stop packets. We had some racy conditions where thread 1 might be sending a packet and thread 2 tries to send a packet to get the thread list and it fails and ends up with an empty list. Packets use a sequence mutex to be able to ensure when you send a packet, you get the resonse. This sequence mutex is take when the process is running, and as we exit the running state and notify our process with the stop packet, we now always get the thread ID list before we do anything and before we can run into race conditions. 

The next step is to have our stop reply packets send the thread list in the actual stop reply packet to avoid a 2 packet overhead of sending the qfThreadInfo + response and qfThreadInfo + response.

llvm-svn: 154376

1) Start the PrivateStateThread stopped, and then in
StartPrivateStateThread, make the private state thread and then
resume it before we say the thread is created.  That way we know it is
listening for events by the time we get out of
StartPrivateStateThread.

2) Backstop running a thread plan when calling Process::RunThreadPlan
on the private state thread with a ThreadPlanBase so that running the
plan doesn't pass its stop events to whatever plans happen to be above
us on the thread plan stack.

llvm-svn: 154368

Clear the "m_actual_stop_info_sp" in the thread during Destroy.  It might be a StopInfoThreadPlan, and that would hold onto members that need to be destroyed while the Full thread is still around.

llvm-svn: 154366

The current ProcessGDBRemote function that updates the threads could end up with an empty list if any other thread had the sequence mutex. We now don't clear the thread list when we can't access it, and we also have changed how lldb_private::Process handles the return code from the:

virtual bool
Process::UpdateThreadList (lldb_private::ThreadList &old_thread_list, 
                       	   lldb_private::ThreadList &new_thread_list) = 0;

A bool is now returned to indicate if the list was actually updated or not and the lldb_private::Process class will only update the stop ID of the validity of the thread list if "true" is returned.

The ProcessGDBRemote also got an extra assertion that will hopefully assert when running debug builds so we can find the source of this issue.

llvm-svn: 154365

Added a packet history object to the GDBRemoteCommunication class that is always remembering the last 512 packets that were sent/received. These packets get dumped if logging gets enabled, or when the new expr lldb::DumpProcessGDBRemotePacketHistory (void *process, const char *log_file_path) global function is called.

llvm-svn: 154354

Fixed an issue that could occur when looking up functions inside of a namespace where if the NamespaceDecl hadn't been parsed yet, we would say a function wasn't in a namespace.

Also improved the logging that happens with "log enable dwarf lookups" is enabled to show when we find matches.

llvm-svn: 154352

Rework how master plans declare themselves.  Also make "PlanIsBasePlan" not rely only on this being the bottom plan in the stack, but allow the plan to declare itself as such.

llvm-svn: 154351

Work around a deadlocking issue where "SBDebugger::MemoryPressureDetected ()" is being called and is causing a deadlock. We now just try and get the lock when trying to trim down the unique modules so we don't deadlock debugger GUI programs until we can find the root cause.

llvm-svn: 154339

llvm-svn: 154255

llvm-svn: 154252