History log of /external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
a1f156aa2695963058615edeabedfcb0f1ca5fab 24-Jun-2013 Han Ming Ong <hanming@apple.com> <rdar://problem/14182286>

Made sure that temporary object created from HarmonizeThreadIdsForProfileData() doesn’t get passed around without creating an object first.

Reviewed by Greg

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@184769 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
3e11c7ec050648ba865f1d451f8cb46fd39072a8 19-Jun-2013 Andy Gibbs <andyg1001@hotmail.co.uk> Sort out a number of mismatched integer types in order to cut down the number of compiler warnings.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@184333 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
761afb822b18c46b2ad84be03f372e90ac1e6143 02-May-2013 Jim Ingham <jingham@apple.com> Recommitting r180831 with trivial fix - remember to return errors if you compute.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@180898 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
411ab47806a478d932926ef7a309ea37edf1f7e7 01-May-2013 Daniel Malea <daniel.malea@intel.com> Reverting 180831 as it crashes TestDefaultConstructorForAPIObjects.py



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@180868 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
b4e08abf4972befc8412bc83a0205fbdc547290e 01-May-2013 Jim Ingham <jingham@apple.com> Added an option to "process detach" to keep the process stopped, if the process plugin (or in the
case of ProcessGDBRemote the stub we are talking to) know how to do that.

rdar://problem/13680832


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@180831 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
952e9dc874944fcdbbb224f3ec4fc2c859376f64 28-Mar-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13521159>

LLDB is crashing when logging is enabled from lldb-perf-clang. This has to do with the global destructor chain as the process and its threads are being torn down.

All logging channels now make one and only one instance that is kept in a global pointer which is never freed. This guarantees that logging can correctly continue as the process tears itself down.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@178191 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
4a5dfcf8ec8303c0bd661132b9945a5173454720 23-Feb-2013 Jason Molenda <jmolenda@apple.com> Fix a handful of remaining assumptions that thread IDs were 32-bits
in the gdb-remote Process plugin files.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@175947 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
04ce77fb8393fbe7ceb84575976a5d2572ab9e66 22-Feb-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13190981>

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.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@175924 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
0df19ccfaa20d43245fea877fcfdfd5b2efb08c9 19-Jan-2013 Han Ming Ong <hanming@apple.com> <rdar://problem/12976277>

Swap in index ids for thread ids in GDBRemoteCommunicationClient. Besides dealing with the async logic, I have to take care of the situation when the inferior paused as well.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@172869 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
fe555673aebe745e5c35412969639ae348ce50d4 19-Dec-2012 Jason Molenda <jmolenda@apple.com> <rdar://problem/11961650>

Update the debugserver "qProcessInfo" implementation to return the
cpu type, cpu subtype, OS and vendor information just like qHostInfo
does so lldb can create an ArchSpec based on the returned values.

Add a new GetProcessArchitecture to GDBRemoteCommunicationClient akin
to GetHostArchitecture. If the qProcessInfo packet is supported,
GetProcessArchitecture will return the cpu type / subtype of the
process -- e.g. a 32-bit user process running on a 64-bit x86_64 Mac
system.

Have ProcessGDBRemote set the Target's architecture based on the
GetProcessArchitecture when we've completed an attach/launch/connect.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@170491 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
d35b7b3bfd21f4fd6b048693563eef1b772ae197 07-Dec-2012 Daniel Malea <daniel.malea@intel.com> More Linux warnings fixes (remove default labels as needed):
- as per http://llvm.org/docs/CodingStandards.html#don-t-use-default-labels-in-fully-covered-switches-over-enumerations

Patch by Matt Kopec!




git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@169633 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
5f35a4be95aed0e5b2cb36f7d785bcbfc67284ae 29-Nov-2012 Daniel Malea <daniel.malea@intel.com> Resolve printf formatting warnings on Linux:
- use macros from inttypes.h for format strings instead of OS-specific types

Patch from Matt Kopec!



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@168945 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
fb9cee64303d36d6fe5d87e63dd8701d1ddb70a9 17-Nov-2012 Han Ming Ong <hanming@apple.com> <rdar://problem/12720514> Sub-TLF: Provide service to profile the inferior

This allows client to query profiling states on the inferior.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@168228 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
37d3fce9f5734964665236365bd2c404f0a32971 13-Oct-2012 Greg Clayton <gclayton@apple.com> Make sure we always use lldb::tid_t for thread IDs so we don't truncate a 64 bit thread ID.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@165862 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
851e30ec6a1b1d2c154bb7d69ed0d05b5fd14705 18-Sep-2012 Greg Clayton <gclayton@apple.com> Stop using the "%z" size_t modifier and cast all size_t values to uint64_t. Some platforms don't support this modification.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@164148 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
73f6b49b568f48755bb5058a3db679c3b9093682 25-Jul-2012 Jim Ingham <jingham@apple.com> Add a call to "sync" a thread state before checkpointing registers in preparation for
calling functions. This is necessary on Mac OS X, since bad things can happen if you set
the registers of a thread that's sitting in a kernel trap.

<rdar://problem/11145013>


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@160756 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
3a458eb1e413d39546b664813bba9f9ac292357e 20-Jul-2012 Jim Ingham <jingham@apple.com> Add "vAttachOrWait" to debugserver, so you can implement "attach to the process if it exists OR wait for it" without race conditions. Use that in lldb.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@160578 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
4a379b1194f3e6b308cd6e80b45d6ca5dd0aafd7 17-Jul-2012 Greg Clayton <gclayton@apple.com> Ran the static analyzer on the codebase and found a few things.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@160338 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
7de2a3b03f37987c67f142ce328cc2484c831468 14-Jul-2012 Enrico Granata <egranata@apple.com> <rdar://problem/11782789> Changes to the watchpoint implementation on ARM so that we single-step before stopping at the WP. This is necessary because on ARM the WP triggers before the opcode is actually executed, so we would be unable to continue since we would keep hitting the WP. We work around this by disabling the WP, single stepping and then putting the WP back in place.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@160199 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
0d2c5410a0b7584ba20a3e0e1a0dd689ae397119 03-Jul-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/11744001>

Fixed an issue where GDB servers that don't support the thread suffix could get registers states incorrectly due to an incorrect assumption that the current register thread (set using the "Hg%x" packet) will always be cached between runs. Now we clear the cached register thred when the process is resumed.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@159603 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
7b3a49b3d69660797832e711018a1b1f6a14e318 28-Jun-2012 Jim Ingham <jingham@apple.com> Make the error message when we time out waiting for debugserver to reply to the qLaunchSuccess packet less cryptic.

<rdar://problem/11754744>

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@159373 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
088684d31c66df959fa2f3840f00b73b79b07756 09-Jun-2012 Jim Ingham <jingham@apple.com> Change the Mutex::Locker class so that it takes the Mutex object and locks it, rather
than being given the pthread_mutex_t from the Mutex and locks that. That allows us to
track ownership of the Mutex better.

Used this to switch the LLDB_CONFIGURATION_DEBUG enabled assert when we can't get the
gdb-remote sequence mutex to assert when the thread that had the mutex releases it. This
is generally more useful information than saying just who failed to get it (since the
code that had it locked often had released it by the time the assert fired.)



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@158240 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
8247e62689a3ddf9c53c214b7f73dfab2f69e086 06-Jun-2012 Jim Ingham <jingham@apple.com> Fix a place in GDBRemoteCommunicationClient::SendContinuePacketAndWaitForReply where we weren't taking
m_interrupt_sent into account. Also don't reset m_interrupt_sent in SendInterrupt but do so in SendPacketAndWaitForResponse
when we know we've handled the interrupt.
Fix a code path through ProcessGDBRemote::DoDestroy where we were tearing down the debug session but
not setting the exit status.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@158043 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
70e167f86c3406d5f583ff9cf8f602d42886d2b9 31-May-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/11486302>

Improve logging a bit.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@157771 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
8ca4fa741acdf7e5e68b28cb8e29225944999135 25-May-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/11529853>

Sending async packets can deadlock a program on darwin. We currently allow breakpoint packets and memory read/write packets (for software breakpoints) to be sent while a program is running. In the GDB remote plug-in, we will interrupt the run, send the async packet and resume (currently with the continue packet that caused the program to resume). If the GDB server supports the "vCont" packet, we might have initially continued with each thread stating it should continue. If new threads show up while we are stopped, which happend when running GCD, we can end up with new threads that we aren't mentioning in the continue list. So we start with a thread list of 1,2,3 and continue:

continue thread 1, continue thread 2, continue thread 3

Now we interrupt and set a breakpoint and we actually have threads 1,2,3,4 now when we are about to resume, yet we send:

continue thread 1, continue thread 2, continue thread 3

Any thread that isn't mentioned is currently going to stay suspended. This causes the deadlock.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@157439 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
7cbdcfb0cefcfd877b507ff2d83e51a1bde3fcc7 23-May-2012 Johnny Chen <johnny.chen@apple.com> Add the capability to display the number of supported hardware watchpoints to the "watchpoint list" command.

Add default Process::GetWatchpointSupportInfo() impl which returns an error of "not supported".
Add "qWatchpointSupportInfo" packet to the gdb communication layer to support this, and modify TestWatchpointCommands.py to test it.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@157345 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
c2c822c939144c45efd206cab933a0ae53f6acf5 15-May-2012 Greg Clayton <gclayton@apple.com> Fixed a typo: "aync" => "async"



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@156797 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
b170aee2daacc83e3d71c3e3acc9d56c89893a7b 08-May-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/11358639>

Switch over to the "*-apple-macosx" for desktop and "*-apple-ios" for iOS triples.

Also make the selection process for auto selecting platforms based off of an arch much better.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@156354 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
e61ec7f0fc290d6dc6f99f9b177567efaf63738e 07-May-2012 Filipe Cabecinhas <me@filcab.net> Remove repeated word.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@156300 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
c8dd570dddf0b73b74db5c1ecb8f18f023f864e7 12-Apr-2012 Greg Clayton <gclayton@apple.com> Remove the GetSequenceMutex timeout that isn't being used in the GDB remote plug-in.

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



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@154603 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
516f0849819d094d4eab39a1f27b770259103ff8 11-Apr-2012 Greg Clayton <gclayton@apple.com> No functionality changes, mostly cleanup.

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.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@154458 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
a1f645e66c8e52ef287b9ab42f521eb57bcf217d 10-Apr-2012 Greg Clayton <gclayton@apple.com> Added a new packet to our GDB remote protocol:

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.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@154380 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
ae932359b80098532f3c3766fa9e6527352fbb67 10-Apr-2012 Greg Clayton <gclayton@apple.com> Trying to solve our disappearing thread issues by making thread list updates safer.

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.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@154365 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
05e4d977e8ec151b165fc8ab3bdcd09bc0599a2c 29-Mar-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/11052174>
<rdar://problem/11051056>

Found a race condition when sending async packets in the ProcessGDBRemote.

A little background: GDB remote clients can only send one packet at a time. You must send a packet and wait for a response. So when we continue, we obviously can't hold up the calling thread waiting for the process to stop again, so we have an async thread in the ProcessGDBRemote whose only job is to run packets that control the inferior process. When you send a continue packet, the only packet you can send is an interrupt packet (which consists of sending a CTRL+C (or a '\x03' byte)). This then stops the inferior and we can send the async packet, and then resume the target. There was a race condition that often happened during stepping where we are doing a source level single step which consists of many instruction steps and a few runs here and there when we step into a function. So the flow looks like:

inst single step
inst single step
inst single step
inst single step
inst single step
step BP and run
inst single step
inst single step
inst single step

Now if we got an async packet while the program is running we get something like:

send --> continue
send --> interrupt
recv <-- interrupt stop reply packet
send --> async packet
recv <-- async response
send --> continue again and wait for actual stop

Problems arise when this was happening when single stepping a thread where we would get:

send --> step thread 123
send --> interrupt
send --> stop reply for thread 123 (from the step)

Now we _might_ have an extra stop reply packet from the "interrupt" which we weren't checking for and we could end up with:

send --> async packet (like memory read!)
recv <-- async response (which is the interrupt stop reply packet)

Now we have the read memroy reply sitting in our buffer and waiting to be used as the reply for the next packet...

To further complicate things, the single step should have exited the async thread since the run control is finished, but now it will continue if it was interrupted.

The fixes I checked in to two major things:
- watch for the extra stop reply if we need to
- make sure we exit from the async thread run loop when the previous run control (like the instruction level single step) is finished.

Needless to say this makes very fast stepping in Xcode much more reliable.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@153629 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
1f9c39c3c146f3c057575f53707e97019f402c46 13-Dec-2011 Jason Molenda <jmolenda@apple.com> When unwinding from the first frame, try to ask the remote debugserver
if this is a mapped/executable region of memory. If it isn't, we've jumped
through a bad pointer and we know how to unwind the stack correctly based
on the ABI.

Previously I had 0x0 special cased but if you jumped to 0x2 on x86_64 one
frame would be skipped because the unwinder would try using the x86_64
ArchDefaultUnwindPlan which relied on the rbp.

Fixes <rdar://problem/10508291>



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@146477 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
d9919d3f46c5069eef065a27f96abc021330d5f3 02-Dec-2011 Greg Clayton <gclayton@apple.com> Process IDs (lldb::pid_t) and thread IDs (lldb::tid_t) are now 64 bit. This
will allow us to represent a process/thread ID using a pointer for the OS
plug-ins where they might want to represent the process or thread ID using
the address of the process or thread structure.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@145644 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
a9385537809ef342c843c5ab972e513742652047 18-Nov-2011 Greg Clayton <gclayton@apple.com> Added optional calls to lldb_private::Process for getting memory region info
from a process and hooked it up to the new packet that was recently added
to our GDB remote executable named debugserver. Now Process has the following
new calls:

virtual Error
Process::GetMemoryRegionInfo (lldb::addr_t load_addr, MemoryRegionInfo &range_info);

virtual uint32_t
GetLoadAddressPermissions (lldb::addr_t load_addr);

Only the first one needs to be implemented by subclasses that can add this
support.

Cleaned up the way the new packet was implemented in debugserver to be more
useful as an API inside debugserver. Also found an error where finding a region
for an address actually will pick up the next region that follows the address
in the query so we also need ot make sure that the address we requested the
region for falls into the region that gets returned.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@144976 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
527154d8e532f27f25af226c9e1dac607c48b5d1 15-Nov-2011 Greg Clayton <gclayton@apple.com> Added a new class to Process.h: ProcessAttachInfo. This class contains enough
info for us to attach by pid, or by name and will also allow us to eventually
do a lot more powerful attaches. If you look at the options for the "platform
process list" command, there are many options which we should be able to
specify. This will allow us to do things like "attach to a process named 'tcsh'
that has a parent process ID of 123", or "attach to a process named 'x' which
has an effective user ID of 345".

I finished up the --shell implementation so that it can be used without the
--tty option in "process launch". The "--shell" option now can take an
optional argument which is the path to the shell to use (or a partial name
like "sh" which we will find using the current PATH environment variable).

Modified the Process::Attach to use the new ProcessAttachInfo as the sole
argument and centralized a lot of code that was in the "process attach"
Execute function so that everyone can take advantage of the powerful new
attach functionality.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@144615 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
b7669b38fc7bdd2351563a5ed86710b4ee123801 28-Oct-2011 Greg Clayton <gclayton@apple.com> <rdar://problem/10357230>

Fixed an issue where async packets were incurring a delay even though they
were sent correctly. We now properly broadcast the private run state being
resumed correctly. Also fixed logging to reflect what is happening.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@143154 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
7e5fa7fc1f8efd24c078e063b2c4b5e13ba5be20 20-Sep-2011 Jason Molenda <jmolenda@apple.com> Update declarations for all functions/methods that accept printf-style
stdarg formats to use __attribute__ format so the compiler can flag
incorrect uses. Fix all incorrect uses. Most of these are innocuous,
a few were resulting in crashes.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@140185 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
89798cc3db1b225f6555cdd07f47ca317c0aae5d 15-Sep-2011 Greg Clayton <gclayton@apple.com> Set the OS in the triple correctly in response to the qHostInfo packet.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@139759 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
153ccd72f52a6cc3595d7614558e2954f67833eb 10-Aug-2011 Greg Clayton <gclayton@apple.com> While tracking down memory consumption issue a few things were needed: the
ability to dump more information about modules in "target modules list". We
can now dump the shared pointer reference count for modules, the pointer to
the module itself (in case performance tools can help track down who has
references to said pointer), and the modification time.

Added "target delete [target-idx ...]" to be able to delete targets when they
are no longer needed. This will help track down memory usage issues and help
to resolve when module ref counts keep getting incremented. If the command gets
no arguments, the currently selected target will be deleted. If any arguments
are given, they must all be valid target indexes (use the "target list"
command to get the current target indexes).

Took care of a bunch of "no newline at end of file" warnings.

TimeValue objects can now dump their time to a lldb_private::Stream object.

Modified the "target modules list --global" command to not error out if there
are no targets since it doesn't require a target.

Fixed an issue in the MacOSX DYLD dynamic loader plug-in where if a shared
library was updated on disk, we would keep using the older one, even if it was
updated.

Don't allow the ModuleList::GetSharedModule(...) to return an empty module.
Previously we could specify a valid path on disc to a module, and specify an
architecture that wasn't contained in that module and get a shared pointer to
a module that wouldn't be able to return an object file or a symbol file. We
now make sure an object file can be extracted prior to adding the shared pointer
to the module to get added to the shared list.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@137196 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
801417e453f8531ac176cd952200587bf15d9ccf 07-Jul-2011 Greg Clayton <gclayton@apple.com> Added "target variable" command that allows introspection of global
variables prior to running your binary. Zero filled sections now get
section data correctly filled with zeroes when Target::ReadMemory
reads from the object file section data.

Added new option groups and option values for file lists. I still need
to hook up all of the options to "target variable" to allow more complete
introspection by file and shlib.

Added the ability for ValueObjectVariable objects to be created with
only the target as the execution context. This allows them to be read
from the object files through Target::ReadMemory(...).

Added a "virtual Module * GetModule()" function to the ValueObject
class. By default it will look to the parent variable object and
return its module. The module is needed when we have global variables
that have file addresses (virtual addresses that are specific to
module object files) and in turn allows global variables to be displayed
prior to running.

Removed all of the unused proxy object support that bit rotted in
lldb_private::Value.

Replaced a lot of places that used "FileSpec::Compare (lhs, rhs) == 0" code
with the more efficient "FileSpec::Equal (lhs, rhs)".

Improved logging in GDB remote plug-in.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@134579 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
20fe30ca112121e963dc5ed0547b46bca72f9620 19-Jun-2011 Peter Collingbourne <peter@pcc.me.uk> Switch from USEC_PER_SEC/NSEC_PER_SEC/NSEC_PER_USEC to TimeValue constants

Fixes the Linux build.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@133370 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
63afdb07641f04aa7b60d895120b056124d3469b 17-Jun-2011 Greg Clayton <gclayton@apple.com> Improved the packet throughput when debugging with GDB remote by over 3x on
darwin (not sure about other platforms).

Modified the communication and connection classes to not require the
BytesAvailable function. Now the "Read(...)" function has a timeout in
microseconds.

Fixed a lot of assertions that were firing off in certain cases and replaced
them with error output and code that can deal with the assertion case.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@133224 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
4a60f9e0a988fe64acaccccc2a15577a8247a4d3 21-May-2011 Greg Clayton <gclayton@apple.com> Centralize the code that gathers the thread ID list from the remote GDB
server so that it happens in command sequence where no other packets can
sneak between.




git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131769 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
139da72165577f073c14f2d5b86191e2c7b21d4c 20-May-2011 Greg Clayton <gclayton@apple.com> Fixed an issue in GDBRemoteCommunicationClient where we weren't listening to
the "payload_length" argument for the "payload" packet data. This meant we
could end up sending random extra data with a packet depending on how the
packet was constructed.

Fixed GDBRemoteRegisterContext to properly save and restore all registers.
Previous fixes had been added to work around the "payload_length" issues fixed
above and aren't needed anymore.

Fix logging in GDBRemoteCommunication to make sure we log the correct packet
data being sent by using the packet length when dumping the packet contents.

Added register definitions for 'arm-lldb' in the "disasm-gdb-remote.pl" script
so if you have a register dump from the GDB remote that doesn't include the
qRegisterInfo packets, you can manually tell the script which registers are
which.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131715 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
628cead3b4ae3d709d10389a3ab026e808dffa9b 19-May-2011 Greg Clayton <gclayton@apple.com> Fixed a crasher that was happened when a log shared pointer wasn't valid.

Fixed ThreadPlanCallFunction::ReportRegisterState(...) to only dump when
verbose logging is enabled and fixed the function to use the new
RegisterValue method of reading registers.

Fixed the GDB remote client to not send a continue packet after receiving
stdout or stderr from the inferior process.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131628 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
5b53e8e170ccda77a6d47c3522d27ad3efcca234 16-May-2011 Greg Clayton <gclayton@apple.com> Properly handle when commands are not unsupported in the GDB remote clients.
Prior to this fix we would often call SendPacketAndWaitForResponse() which
returns the number of bytes in the response. The UNSUPPORTED response in the
GDB remote protocol is zero bytes and we were checking for it inside an if
statement:

if (SendPacketAndWaitForResponse(...))
{
if (response.IsUnsupportedResponse())
{
// UNSUPPORTED...
// This will never happen...
}
}

We now handle is properly as:

if (SendPacketAndWaitForResponse(...))
{
}
else
{
// UNSUPPORTED...
}



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131393 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
2f085c6ca2895663687dca704589478ff040b849 15-May-2011 Greg Clayton <gclayton@apple.com> Added the ability to get the return value from a ThreadPlanCallFunction
thread plan. In order to get the return value, you can call:

void
ThreadPlanCallFunction::RequestReturnValue (lldb::ValueSP &return_value_sp);

This registers a shared pointer to a return value that will get filled in if
everything goes well. After the thread plan is run the return value will be
extracted for you.

Added an ifdef to be able to switch between the LLVM MCJIT and the standand JIT.
We currently have the standard JIT selected because we have some work to do to
get the MCJIT fuctioning properly.

Added the ability to call functions with 6 argument in the x86_64 ABI.

Added the ability for GDBRemoteCommunicationClient to detect if the allocate
and deallocate memory packets are supported and to not call allocate memory
("_M") or deallocate ("_m") if we find they aren't supported.

Modified the ProcessGDBRemote::DoAllocateMemory(...) and ProcessGDBRemote::DoDeallocateMemory(...)
to be able to deal with the allocate and deallocate memory packets not being
supported. If they are not supported, ProcessGDBRemote will switch to calling
"mmap" and "munmap" to allocate and deallocate memory instead using our
trivial function call support.

Modified the "void ProcessGDBRemote::DidLaunchOrAttach()" to correctly ignore
the qHostInfo triple information if any was specified in the target. Currently
if the target only specifies an architecture when creating the target:

(lldb) target create --arch i386 a.out

Then the vendor, os and environemnt will be adopted by the target.

If the target was created with any triple that specifies more than the arch:

(lldb) target create --arch i386-unknown-unknown a.out

Then the target will maintain its triple and not adopt any new values. This
can be used to help force bare board debugging where the dynamic loader for
static files will get used and users can then use "target modules load ..."
to set addressses for any files that are desired.

Added back some convenience functions to the lldb_private::RegisterContext class
for writing registers with unsigned values. Also made all RegisterContext
constructors explicit to make sure we know when an integer is being converted
to a RegisterValue.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131370 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
989816b9505219cd67ce044d655c54ac86ecf64b 14-May-2011 Greg Clayton <gclayton@apple.com> Expand the ABI prepare trivial function call to allow 6 simple args.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131334 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
a4582404fa50f89485e69a17281673147217d64f 08-May-2011 Greg Clayton <gclayton@apple.com> Fixed not being able to launch the i386 slice of a universal binary by adding
a new "QLaunchArch:<arch-name>" where <arch-name> is the architecture name.
This allows us to remotely launch a debugserver and then set the architecture
for the binary we will launch.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131064 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
b72d0f098e45936fa72e26b1a026c603e17e2d6c 12-Apr-2011 Greg Clayton <gclayton@apple.com> Moved the execution context that was in the Debugger into
the CommandInterpreter where it was always being used.

Make sure that Modules can track their object file offsets correctly to
allow opening of sub object files (like the "__commpage" on darwin).

Modified the Platforms to be able to launch processes. The first part of this
move is the platform soon will become the entity that launches your program
and when it does, it uses a new ProcessLaunchInfo class which encapsulates
all process launching settings. This simplifies the internal APIs needed for
launching. I want to slowly phase out process launching from the process
classes, so for now we can still launch just as we used to, but eventually
the platform is the object that should do the launching.

Modified the Host::LaunchProcess in the MacOSX Host.mm to correctly be able
to launch processes with all of the new eLaunchFlag settings. Modified any
code that was manually launching processes to use the Host::LaunchProcess
functions.

Fixed an issue where lldb_private::Args had implicitly defined copy
constructors that could do the wrong thing. This has now been fixed by adding
an appropriate copy constructor and assignment operator.

Make sure we don't add empty ModuleSP entries to a module list.

Fixed the commpage module creation on MacOSX, but we still need to train
the MacOSX dynamic loader to not get rid of it when it doesn't have an entry
in the all image infos.

Abstracted many more calls from in ProcessGDBRemote down into the
GDBRemoteCommunicationClient subclass to make the classes cleaner and more
efficient.

Fixed the default iOS ARM register context to be correct and also added support
for targets that don't support the qThreadStopInfo packet by selecting the
current thread (only if needed) and then sending a stop reply packet.

Debugserver can now start up with a --unix-socket (-u for short) and can
then bind to port zero and send the port it bound to to a listening process
on the other end. This allows the GDB remote platform to spawn new GDB server
instances (debugserver) to allow platform debugging.







git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@129351 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
f15996eea072cdaa8a092f22d3a1212b3d95f0ec 08-Apr-2011 Greg Clayton <gclayton@apple.com> Modified the ArchSpec to take an optional "Platform *" when setting the triple.
This allows you to have a platform selected, then specify a triple using
"i386" and have the remaining triple items (vendor, os, and environment) set
automatically.

Many interpreter commands take the "--arch" option to specify an architecture
triple, so now the command options needed to be able to get to the current
platform, so the Options class now take a reference to the interpreter on
construction.

Modified the build LLVM building in the Xcode project to use the new
Xcode project level user definitions:

LLVM_BUILD_DIR - a path to the llvm build directory
LLVM_SOURCE_DIR - a path to the llvm sources for the llvm that will be used to build lldb
LLVM_CONFIGURATION - the configuration that lldb is built for (Release,
Release+Asserts, Debug, Debug+Asserts).

I also changed the LLVM build to not check if "lldb/llvm" is a symlink and
then assume it is a real llvm build directory versus the unzipped llvm.zip
package, so now you can actually have a "lldb/llvm" directory in your lldb
sources.




git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@129112 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
baf01e0ba101b98764a1eb62f45e739f0d1a1e89 07-Apr-2011 Stephen Wilson <wilsons@start.ca> Removed use of NSEC_PER_SEC.

NSEC_PER_SEC is not defined in sys/time.h on Linux. Replaced that macro with a
static constant inside TimeValue.

Patch by Marco Minutoli.




git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@129071 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
06d7cc86937caca0acf2b990a02a641dc9c7579a 04-Apr-2011 Greg Clayton <gclayton@apple.com> Added a speed test to the GDBRemoteCommunicationClient and
GDBRemoteCommunicationServer classes. This involved adding a new packet
named "qSpeedTest" which can test the speed of a packet send/response pairs
using a wide variety of send/recv packet sizes.

Added a few new connection classes: one for shared memory, and one for using
mach messages (Apple only). The mach message stuff is experimental and not
working yet, but added so I don't lose the code. The shared memory stuff
uses pretty standard calls to setup shared memory.




git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@128837 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
ff39f746ebaa3710c44ba49bd9b0a6cf05f60a3f 01-Apr-2011 Greg Clayton <gclayton@apple.com> Added the ability to get a broadcaster event name for a given broadcaster
event.

Modified the ProcessInfo structure to contain all process arguments. Using the
new function calls on MacOSX allows us to see the full process name, not just
the first 16 characters.

Added a new platform command: "platform process info <pid> [<pid> <pid> ...]"
that can be used to get detailed information for a process including all
arguments, user and group info and more.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@128694 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
24bc5d9bfad2a1c562c27e7cf37e1c56d85c45e7 30-Mar-2011 Greg Clayton <gclayton@apple.com> Many improvements to the Platform base class and subclasses. The base Platform
class now implements the Host functionality for a lot of things that make
sense by default so that subclasses can check:

int
PlatformSubclass::Foo ()
{
if (IsHost())
return Platform::Foo (); // Let the platform base class do the host specific stuff

// Platform subclass specific code...
int result = ...
return result;
}

Added new functions to the platform:

virtual const char *Platform::GetUserName (uint32_t uid);
virtual const char *Platform::GetGroupName (uint32_t gid);

The user and group names are cached locally so that remote platforms can avoid
sending packets multiple times to resolve this information.

Added the parent process ID to the ProcessInfo class.

Added a new ProcessInfoMatch class which helps us to match processes up
and changed the Host layer over to using this new class. The new class allows
us to search for processs:
1 - by name (equal to, starts with, ends with, contains, and regex)
2 - by pid
3 - And further check for parent pid == value, uid == value, gid == value,
euid == value, egid == value, arch == value, parent == value.

This is all hookup up to the "platform process list" command which required
adding dumping routines to dump process information. If the Host class
implements the process lookup routines, you can now lists processes on
your local machine:

machine1.foo.com % lldb
(lldb) platform process list
PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME
====== ====== ========== ========== ========== ========== ======================== ============================
99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge
94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker
94852 244 username usergroup username usergroup x86_64-apple-darwin Safari
94727 244 username usergroup username usergroup x86_64-apple-darwin Xcode
92742 92710 username usergroup username usergroup i386-apple-darwin debugserver


This of course also works remotely with the lldb-platform:

machine1.foo.com % lldb-platform --listen 1234

machine2.foo.com % lldb
(lldb) platform create remote-macosx
Platform: remote-macosx
Connected: no
(lldb) platform connect connect://localhost:1444
Platform: remote-macosx
Triple: x86_64-apple-darwin
OS Version: 10.6.7 (10J869)
Kernel: Darwin Kernel Version 10.7.0: Sat Jan 29 15:17:16 PST 2011; root:xnu-1504.9.37~1/RELEASE_I386
Hostname: machine1.foo.com
Connected: yes
(lldb) platform process list
PID PARENT USER GROUP EFF USER EFF GROUP TRIPLE NAME
====== ====== ========== ========== ========== ========== ======================== ============================
99556 244 username usergroup username usergroup x86_64-apple-darwin trustevaluation
99548 65539 username usergroup username usergroup x86_64-apple-darwin lldb
99538 1 username usergroup username usergroup x86_64-apple-darwin FileMerge
94943 1 username usergroup username usergroup x86_64-apple-darwin mdworker
94852 244 username usergroup username usergroup x86_64-apple-darwin Safari

The lldb-platform implements everything with the Host:: layer, so this should
"just work" for linux. I will probably be adding more stuff to the Host layer
for launching processes and attaching to processes so that this support should
eventually just work as well.

Modified the target to be able to be created with an architecture that differs
from the main executable. This is needed for iOS debugging since we can have
an "armv6" binary which can run on an "armv7" machine, so we want to be able
to do:

% lldb
(lldb) platform create remote-ios
(lldb) file --arch armv7 a.out

Where "a.out" is an armv6 executable. The platform then can correctly decide
to open all "armv7" images for all dependent shared libraries.

Modified the disassembly to show the current PC value. Example output:

(lldb) disassemble --frame
a.out`main:
0x1eb7: pushl %ebp
0x1eb8: movl %esp, %ebp
0x1eba: pushl %ebx
0x1ebb: subl $20, %esp
0x1ebe: calll 0x1ec3 ; main + 12 at test.c:18
0x1ec3: popl %ebx
-> 0x1ec4: calll 0x1f12 ; getpid
0x1ec9: movl %eax, 4(%esp)
0x1ecd: leal 199(%ebx), %eax
0x1ed3: movl %eax, (%esp)
0x1ed6: calll 0x1f18 ; printf
0x1edb: leal 213(%ebx), %eax
0x1ee1: movl %eax, (%esp)
0x1ee4: calll 0x1f1e ; puts
0x1ee9: calll 0x1f0c ; getchar
0x1eee: movl $20, (%esp)
0x1ef5: calll 0x1e6a ; sleep_loop at test.c:6
0x1efa: movl $12, %eax
0x1eff: addl $20, %esp
0x1f02: popl %ebx
0x1f03: leave
0x1f04: ret

This can be handy when dealing with the new --line options that was recently
added:

(lldb) disassemble --line
a.out`main + 13 at test.c:19
18 {
-> 19 printf("Process: %i\n\n", getpid());
20 puts("Press any key to continue..."); getchar();
-> 0x1ec4: calll 0x1f12 ; getpid
0x1ec9: movl %eax, 4(%esp)
0x1ecd: leal 199(%ebx), %eax
0x1ed3: movl %eax, (%esp)
0x1ed6: calll 0x1f18 ; printf

Modified the ModuleList to have a lookup based solely on a UUID. Since the
UUID is typically the MD5 checksum of a binary image, there is no need
to give the path and architecture when searching for a pre-existing
image in an image list.

Now that we support remote debugging a bit better, our lldb_private::Module
needs to be able to track what the original path for file was as the platform
knows it, as well as where the file is locally. The module has the two
following functions to retrieve both paths:

const FileSpec &Module::GetFileSpec () const;
const FileSpec &Module::GetPlatformFileSpec () const;





git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@128563 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
b344843f75ef893762c93fd0a22d2d45712ce74d 24-Mar-2011 Greg Clayton <gclayton@apple.com> Fixed the LLDB build so that we can have private types, private enums and
public types and public enums. This was done to keep the SWIG stuff from
parsing all sorts of enums and types that weren't needed, and allows us to
abstract our API better.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@128239 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
58e26e0935138225477fd61283215ceff2068899 24-Mar-2011 Greg Clayton <gclayton@apple.com> Did a lot more work on abtracting and organizing the platforms.

On Mac OS X we now have 3 platforms:
PlatformDarwin - must be subclassed to fill in the missing pure virtual funcs
but this implements all the common functionality between
remote-macosx and remote-ios. It also allows for another
platform to be used (remote-gdb-server for now) when doing
remote connections. Keeping this pluggable will allow for
flexibility.
PlatformMacOSX - Now implements both local and remote macosx desktop platforms.
PlatformRemoteiOS - Remote only iOS that knows how to locate SDK files in the
cached SDK locations on the host.

A new agnostic platform has been created:
PlatformRemoteGDBServer - this implements the platform using the GDB remote
protocol and uses the built in lldb_private::Host
static functions to implement many queries.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@128193 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
cb8977d726be451df9978a74088435667fa37da2 23-Mar-2011 Greg Clayton <gclayton@apple.com> Added new platform commands:

platform connect <args>
platform disconnect

Each platform can decide the args they want to use for "platform connect". I
will need to add a function that gets the connect options for the current
platform as each one can have different options and argument counts.

Hooked up more functionality in the PlatformMacOSX and PlatformRemoteiOS.
Also started an platform agnostic PlatformRemoteGDBServer.cpp which can end
up being used by one or more actual platforms. It can also be specialized and
allow for platform specific commands.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@128123 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp
61d043bbb1a1a20abf01dc73fa50c1ca0a46d71d 22-Mar-2011 Greg Clayton <gclayton@apple.com> Split the GDBRemoteCommunication class into three classes:
GDBRemoteCommunication - The base GDB remote communication class
GDBRemoteCommunicationClient - designed to be used for clients the connect to
a remote GDB server
GDBRemoteCommunicationServer - designed to be used on the server side of a
GDB server implementation.





git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@128070 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationClient.cpp