History log of /external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
Revision Date Author Comments (<<< Hide modified files) (Show modified files >>>)
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/GDBRemoteRegisterContext.cpp
a46013bde54626b68cd2013b108f73a205f4b29a 01-May-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13700260>
<rdar://problem/13723772>

Modified the lldb_private::Thread to work much better with the OperatingSystem plug-ins. Operating system plug-ins can now return have a "core" key/value pair in each thread dictionary for the OperatingSystemPython plug-ins which allows the core threads to be contained with memory threads. It also allows these memory threads to be stepped, resumed, and controlled just as if they were the actual backing threads themselves.

A few things are introduced:
- lldb_private::Thread now has a GetProtocolID() method which returns the thread protocol ID for a given thread. The protocol ID (Thread::GetProtocolID()) is usually the same as the thread id (Thread::GetID()), but it can differ when a memory thread has its own id, but is backed by an actual API thread.
- Cleaned up the Thread::WillResume() code to do the mandatory parts in Thread::ShouldResume(), and let the thread subclasses override the Thread::WillResume() which is now just a notification.
- Cleaned up ClearStackFrames() implementations so that fewer thread subclasses needed to override them
- Changed the POSIXThread class a bit since it overrode Thread::WillResume(). It is doing the wrong thing by calling "Thread::SetResumeState()" on its own, this shouldn't be done by thread subclasses, but the current code might rely on it so I left it in with a TODO comment with an explanation.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@180886 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.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/GDBRemoteRegisterContext.cpp
3019c8e4f0a1271e3322eb2bfabe98e780d7630a 09-Mar-2013 Greg Clayton <gclayton@apple.com> Remove my print statements I was using for debugging.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@176753 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
ca97fbbe67ff8c59f5a2ed76d1c5f6a3c93d1a57 09-Mar-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13384282>

As much as I hate to leave this hacky code in that adds some d and q registers to ARM registers, I must leave it in.

The code is now fixed to not just assume ANY arm target will have registers in a certain order. We now verify the common regs are the same name and byte size before adding the d and q regs.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@176752 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
36da2aa6dc5ad9994b638ed09eb81c44cc05540b 25-Jan-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13069948>

Major fixed to allow reading files that are over 4GB. The main problems were that the DataExtractor was using 32 bit offsets as a data cursor, and since we mmap all of our object files we could run into cases where if we had a very large core file that was over 4GB, we were running into the 4GB boundary.

So I defined a new "lldb::offset_t" which should be used for all file offsets.

After making this change, I enabled warnings for data loss and for enexpected implicit conversions temporarily and found a ton of things that I fixed.

Any functions that take an index internally, should use "size_t" for any indexes and also should return "size_t" for any sizes of collections.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@173463 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
c290ba49b79c88ace8e5c58917489415e429ef01 21-Jan-2013 Greg Clayton <gclayton@apple.com> <rdar://problem/13020634>

Fixed the 32, 16, and 8 bit pseudo regs for x86_64 (real reg of "rax" which subvalues "eax", "ax", etc...) to correctly get updated when stepping. Also fixed it so actual registers can specify what other registers must be invalidated when a register is modified. Previously, only pseudo registers could invalidate other registers.

Modified the LLDB qRegisterInfo extension to the GDB remote interface to support specifying the containing registers with the new "container-regs" key whose value is a comma separated list of register numbers. Also added a "invalidate-regs" key whose value is also a comma separated list of register numbers.

Removed the hack GDBRemoteDynamicRegisterInfo::Addx86_64ConvenienceRegisters() function and modified "debugserver" to specify the registers correctly using the new "container-regs" and "invalidate-regs" keys.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@173096 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.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/GDBRemoteRegisterContext.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/GDBRemoteRegisterContext.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/GDBRemoteRegisterContext.cpp
fc34abb897227f88f098854167d9f96822b8daf8 23-May-2012 Johnny Chen <johnny.chen@apple.com> Add more convenience registers to x86_64 and a simple test scenario:

self.expect("expr -- $ax == (($ah << 8) | $al)",
substrs = ['true'])


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@157302 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
8a178b645175259f33a03bf4ebf6ca46cf1064c9 22-May-2012 Johnny Chen <johnny.chen@apple.com> The RegisterInfo descriptors for the convenience registers can specify an offset to be added to the offset as derived from
the value_regs field, which is useful for future expansion purposes. As of now, we have:

calculated_offset_of_eax = offset_of_rax + (offset_of_eax_from_the_descriptor which is 0)


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@157275 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
627ca95187f5ff0fa51fd339891f24e0f7da408d 22-May-2012 Johnny Chen <johnny.chen@apple.com> Fix wrong offset of eax and friends pointed out by Greg.

rdar://problem/11487457


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@157272 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
d2e3066f7e7212adac4ca81d67be0fa706361d16 22-May-2012 Johnny Chen <johnny.chen@apple.com> rdar://problem/11487457

Add convenience registers eax, ebx, ecx, edx, edi, esi, ebp, esp to the 'register read' command for x86_64.
Add a GDBRemoteRegisterContext::Addx86_64ConvenienceRegisters() method called from ProcessGDBRemote::BuildDynamicRegisterInfo().
Servicing of eax, for example, is accomplished by delegating to rax with an adjusted offset into the register context.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@157230 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
08af5983cb349e7167f3832d00d36ca611bfa2f1 16-May-2012 Johnny Chen <johnny.chen@apple.com> Include llvm/ADT/STLExtras.h from lldb/Utility/Utils.h and use llvm::array_lengthof(), instead.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@156876 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
b7cdd6ce21c735292d468510c95f7d2316f54b9c 14-May-2012 Johnny Chen <johnny.chen@apple.com> Fix missing NEON registers for the 'register read' command with the lldb debugserver which supports the 'qRegisterInfo' packet
that dynamically discovers remote register context information.

o GDBRemoteRegisterContext.h:

Change the prototype of HardcodeARMRegisters() to take a boolean flag, which now becomes

void
HardcodeARMRegisters(bool from_scratch);

o GDBRemoteRegisterContext.cpp:

HardcodeARMRegisters() now checks the from_scratch flag and decides whether to add composite registers to the already
existing primordial registers based on a table called g_composites which describes the composite registers.

o ProcessGDBRemote.cpp:

Modify the logic of ProcessGDBRemote::BuildDynamicRegisterInfo() to call m_register_info.HardcodeARMRegisters()
with the newly introduced 'bool from_scrach' flag.

rdar://problem/10652076


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@156773 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
13bf85ccdb13e25375497ff61bcee489b9f94526 26-Apr-2012 Greg Clayton <gclayton@apple.com> Patch from Filipe Cabecinhas.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@155644 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
ceb7a52eaeb9d4265a577c55f7262d4e78063566 20-Apr-2012 Jim Ingham <jingham@apple.com> Missed one place where the assert should have been in a #ifdef. Thanks Jason.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@155175 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
92e6acda6b19fdb3359b7496c765245c99733c05 19-Apr-2012 Jim Ingham <jingham@apple.com> In debug mode, assert when we fail to get the sequence mutex. We need to remove as many places where this can happen as possible.

git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@155138 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
3355946190428830d0fe7b51a4433b0aefc64362 13-Apr-2012 Greg Clayton <gclayton@apple.com> 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.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@154704 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.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/GDBRemoteRegisterContext.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/GDBRemoteRegisterContext.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/GDBRemoteRegisterContext.cpp
74351ba53006b7fb17a5a32ac95c7af87bb03e8c 02-Mar-2012 Johnny Chen <johnny.chen@apple.com> rdar://problem/10652076

Add logic to GDBRemoteRegisterContext class to be able to read/write a "composite" register
which has "primordial" registers as its constituents. In particular, Read/WriteRegisterBytes()
now delegate to Get/SetPrimordialRegister() helper methods to read/write register contents.

Also modify RegisterValue class to be able to parse "register write" string value for the
NEON quadword registers which is displayed as a vector of uint8's.

Example:

(lldb) register write q0 "{0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10}"
(lldb) register read q0
q0 = {0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08 0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10}
(lldb) register read --format uint8_t[] s0
s0 = {0x01 0x02 0x03 0x04}
(lldb) register read --format uint8_t[] d0
d0 = {0x01 0x02 0x03 0x04 0x05 0x06 0x07 0x08}
(lldb) register read --format uint8_t[] d1
d1 = {0x09 0x0a 0x0b 0x0c 0x0d 0x0e 0x0f 0x10}


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151939 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
a330f97376b0b644c07b47357c3fe5123a304dfd 29-Feb-2012 Johnny Chen <johnny.chen@apple.com> Fix a typo in comment.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151759 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
f5c33960ceae3108e6324498d17bbb3ae79301e0 29-Feb-2012 Johnny Chen <johnny.chen@apple.com> rdar://problem/10652076

Incremental check in to calculate the offsets of registers correctly. Registers can be primordial or composite,
for example, r0-r12 are primordial, s0-s31 are primordial, while q0 is composite consisting of (s0, s1, s2, s3).
Modify q0-q8 to be composed of the primordial s0-s31 registers.


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151757 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
402607fe513617c06282d4ae479522e244a53b71 29-Feb-2012 Johnny Chen <johnny.chen@apple.com> rdar://problem/10652076

Initial step -- infrastructure change -- to fix the bug. Change the RegisterInfo data structure
to contain two additional fields (uint32_t *value_rges and uint32_t *invalidate_regs) to facilitate
architectures which have register mapping.

Update all existing RegsiterInfo arrays to have two extra NULL's (the additional fields) in each row,
GDBRemoteRegisterContext.cpp is modified to add d0-d15 and q0-q15 register info entries which take
advantage of the value_regs field to specify the containment relationship:

d0 -> (s0, s1)
...
d15 -> (s30, s31)
q0 -> (d0, d1)
...
q15 -> (d30, d31)


git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151686 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
f4124deeb9532044a38c0774ced872f2709347da 21-Feb-2012 Greg Clayton <gclayton@apple.com> Thread hardening part 3. Now lldb_private::Thread objects have std::weak_ptr
objects for the backlink to the lldb_private::Process. The issues we were
running into before was someone was holding onto a shared pointer to a
lldb_private::Thread for too long, and the lldb_private::Process parent object
would get destroyed and the lldb_private::Thread had a "Process &m_process"
member which would just treat whatever memory that used to be a Process as a
valid Process. This was mostly happening for lldb_private::StackFrame objects
that had a member like "Thread &m_thread". So this completes the internal
strong/weak changes.

Documented the ExecutionContext and ExecutionContextRef classes so that our
LLDB developers can understand when and where to use ExecutionContext and
ExecutionContextRef objects.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@151009 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
43f280c6458f4d9c81e8308b520a2d4a3cacd985 08-Jan-2012 Greg Clayton <gclayton@apple.com> <rdar://problem/10660369>

Fixed the default ARM regiter set to be able to refer to "r7" as "fp" for the apple debugserver.



git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@147746 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
444e35b5fdf15a25a427285650f06f1390e62c75 19-Oct-2011 Greg Clayton <gclayton@apple.com> Moved lldb::user_id_t values to be 64 bit. This was going to be needed for
process IDs, and thread IDs, but was mainly needed for for the UserID's for
Types so that DWARF with debug map can work flawlessly. With DWARF in .o files
the type ID was the DIE offset in the DWARF for the .o file which is not
unique across all .o files, so now the SymbolFileDWARFDebugMap class will
make the .o file index part (the high 32 bits) of the unique type identifier
so it can uniquely identify the types.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@142534 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
107e53da8bdca540db8b734ed237688eaeee85c5 06-Jul-2011 Greg Clayton <gclayton@apple.com> Fixed some issues with ARM backtraces by not processing any push/pop
instructions if they are conditional. Also fixed issues where the PC wasn't
getting bit zero stripped for ARM targets when a stack frame was thumb. We
now properly call through the GetOpcodeLoadAddress() functions to make sure
the addresses are properly stripped for any targets that may decorate up
their addresses.

We now don't pass the SIGSTOP signals along. We can revisit this soon, but
currently this was interfering with debugging some older ARM targets that
don't have vCont support in the GDB server.




git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@134461 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
04d397c5e251eaa5f520dbe6381d2a82303350e1 23-May-2011 Greg Clayton <gclayton@apple.com> Fixed an issue in the EmulateInstructionARM there the IT opcode was trying to
parse NOP instructions. I added the new table entries for the NOP for the
plain NOP, Yield, WFE, WFI, and SEV variants. Modified the opcode emulation
function EmulateInstructionARM::EmulateMOVRdSP(...) to notify us when it is
creating a frame. Also added an abtract way to detect the frame pointer
register for both the standard ARM ABI and for Darwin.

Fixed GDBRemoteRegisterContext::WriteAllRegisterValues(...) to correctly be
able to individually write register values back if case the 'G' packet is
not implemented or returns an error.

Modified the StopInfoMachException to "trace" stop reasons. On ARM we currently
use the BVR/BCR register pairs to say "stop when the PC is not equal to the
current PC value", and this results in a EXC_BREAKPOINT mach exception that
has 0x102 in the code.

Modified debugserver to create the short option string from long option
definitions to make sure it doesn't get out of date. The short option string
was missing many of the newer short option values due to a modification of
the long options defs, and not modifying the short option string.





git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131911 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.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/GDBRemoteRegisterContext.cpp
b9e8f6e7a374d9313f89193e90ae41ef91712e5b 18-May-2011 Greg Clayton <gclayton@apple.com> Added a way to resolve an load address from a target:

bool
Address::SetLoadAddress (lldb::addr_t load_addr, Target *target);

Added an == and != operator to RegisterValue.

Modified the ThreadPlanTracer to use RegisterValue objects to store the
register values when single stepping. Also modified the output to be a bit
less wide.

Fixed the ABIMacOSX_arm to not overwrite stuff on the stack. Also made the
trivial function call be able to set the ARM/Thumbness of the target
correctly, and also sets the return value ARM/Thumbness.

Fixed the encoding on the arm s0-s31 and d16 - d31 registers when the default
register set from a standard GDB server register sets.







git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131517 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
aeb922cf50611901b9e1e66efcc9b05e7a627c1e 17-May-2011 Greg Clayton <gclayton@apple.com> Fixed an issue that broke expression parsing related to backing up
all register values. There is some junk that was appearing at the end
of the result the 'g' packet (read all register values). This function
was being called in:

bool
GDBRemoteRegisterContext::ReadAllRegisterValues (lldb::DataBufferSP &data_sp)

Then the packet data for the 'G' packet (write all registers) was being
placed into "data_sp" so the:

bool
GDBRemoteRegisterContext::WriteAllRegisterValues (const lldb::DataBufferSP &data_sp)

could restore it. In attempting to clean up the extra junk at the end of this
packet data, the packet was getting truncated.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131468 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
3058197753e56a7ea9f4c5784e460a3b977d7bd0 17-May-2011 Greg Clayton <gclayton@apple.com> Fixed the "mmap" to work on MacOSX/darwin by supplying the correct arguemnts.

Modified ClangUserExpression and ClangUtilityFunction to display the actual
error (if one is available) that made the JIT fail instead of a canned
response.

Fixed the restoring of all register values when the 'G' packet doesn't work
to use the correct data.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131454 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
efe0b80e66ce326b23ad070b4eebcd3070c310de 16-May-2011 Greg Clayton <gclayton@apple.com> Add support for the 'G' packet not being implemented or returning an error.
If we are asked to restore all register values, we need to fall back to
restoring each register one by one.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131398 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
8c2d6099c3b9973e26918f4e7f7819696efafc58 15-May-2011 Greg Clayton <gclayton@apple.com> Fixed the default ARM registers to have the generic argument
definitions and names.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131387 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
061b79dbf1fefaf157d414747e98a463a0f32eda 09-May-2011 Greg Clayton <gclayton@apple.com> While implementing unwind information using UnwindAssemblyInstEmulation I ran
into some cleanup I have been wanting to do when reading/writing registers.
Previously all RegisterContext subclasses would need to implement:

virtual bool
ReadRegisterBytes (uint32_t reg, DataExtractor &data);

virtual bool
WriteRegisterBytes (uint32_t reg, DataExtractor &data, uint32_t data_offset = 0);

There is now a new class specifically designed to hold register values:
lldb_private::RegisterValue

The new register context calls that subclasses must implement are:

virtual bool
ReadRegister (const RegisterInfo *reg_info, RegisterValue &reg_value) = 0;

virtual bool
WriteRegister (const RegisterInfo *reg_info, const RegisterValue &reg_value) = 0;

The RegisterValue class must be big enough to handle any register value. The
class contains an enumeration for the value type, and then a union for the
data value. Any integer/float values are stored directly in an appropriate
host integer/float. Anything bigger is stored in a byte buffer that has a length
and byte order. The RegisterValue class also knows how to copy register value
bytes into in a buffer with a specified byte order which can be used to write
the register value down into memory, and this does the right thing when not
all bytes from the register values are needed (getting a uint8 from a uint32
register value..).

All RegiterContext and other sources have been switched over to using the new
regiter value class.




git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@131096 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.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/GDBRemoteRegisterContext.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/GDBRemoteRegisterContext.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/GDBRemoteRegisterContext.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/GDBRemoteRegisterContext.cpp
c97bfdb5e9770f59872352197d277f9d7b1a9a49 10-Mar-2011 Greg Clayton <gclayton@apple.com> Centralize the GDB remote timeout value into the GDBRemoteCommunication as a
member variable (m_packet_timeout which is a value in seconds). This value is
then used for all packets sent to/from the remote GDB server.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@127392 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
c3c4661c6a7527580e605dbb69bef7634971fe13 15-Feb-2011 Greg Clayton <gclayton@apple.com> All UnwindPlan objects are now passed around as shared pointers.

ArchDefaultUnwindPlan plug-in interfaces are now cached per architecture
instead of being leaked for every frame.

Split the ArchDefaultUnwindPlan_x86 into ArchDefaultUnwindPlan_x86_64 and
ArchDefaultUnwindPlan_i386 interfaces.

There were sporadic crashes that were due to something leaking or being
destroyed when doing stack crawls. This patch should clear up these issues.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@125541 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
cd548034fa23113e995b8463d14f910ba2f7298c 01-Feb-2011 Greg Clayton <gclayton@apple.com> Endian patch from Kirk Beitz that allows better cross platform building.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@124643 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
c71899ef308e6134d1b0ca5f30cbc64414855e1a 18-Jan-2011 Greg Clayton <gclayton@apple.com> Thread safety changes in debugserver and also in the process GDB remote plugin.
I added support for asking if the GDB remote server supports thread suffixes
for packets that should be thread specific (register read/write packets) because
the way the GDB remote protocol does it right now is to have a notion of a
current thread for register and memory reads/writes (set via the "$Hg%x" packet)
and a current thread for running ("$Hc%x"). Now we ask the remote GDB server
if it supports adding the thread ID to the register packets and we enable
that feature in LLDB if supported. This stops us from having to send a bunch
of packets that update the current thread ID to some value which is prone to
error, or extra packets.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@123762 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
a875b64ab8d258b28959d05eea37cb5dfdd72730 09-Jan-2011 Greg Clayton <gclayton@apple.com> Put more smarts into the RegisterContext base class. Now the base class has
a method:

void RegisterContext::InvalidateIfNeeded (bool force);

Each time this function is called, when "force" is false, it will only call
the pure virtual "virtual void RegisterContext::InvalideAllRegisters()" if
the register context's stop ID doesn't match that of the process. When the
stop ID doesn't match, or "force" is true, the base class will clear its
cached registers and the RegisterContext will update its stop ID to match
that of the process. This helps make it easier to correctly flush the register
context (possibly from multiple locations depending on when and where new
registers are availabe) without inadvertently clearing the register cache
when it doesn't need to be.

Modified the ProcessGDBRemote plug-in to be much more efficient when it comes
to:
- caching the expedited registers in the stop reply packets (we were ignoring
these before and it was causing us to read at least three registers every
time we stopped that were already supplied in the stop reply packet).
- When a thread has no stop reason, don't keep asking for the thread stopped
info. Prior to this fix we would continually send a qThreadStopInfo packet
over and over when any thread stop info was requested. We now note the stop
ID that the stop info was requested for and avoid multiple requests.

Cleaned up some of the expression code to not look for ClangExpressionVariable
objects up by name since they are now shared pointers and we can just look for
the exact pointer match and avoid possible errors.

Fixed an bug in the ValueObject code that would cause children to not be
displayed.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@123127 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
08d7d3ae16110aa68ed40c161eac8571aeb94cd9 06-Jan-2011 Greg Clayton <gclayton@apple.com> Fixed issues with RegisterContext classes and the subclasses. There was
an issue with the way the UnwindLLDB was handing out RegisterContexts: it
was making shared pointers to register contexts and then handing out just
the pointers (which would get put into shared pointers in the thread and
stack frame classes) and cause double free issues. MallocScribble helped to
find these issues after I did some other cleanup. To help avoid any
RegisterContext issue in the future, all code that deals with them now
returns shared pointers to the register contexts so we don't end up with
multiple deletions. Also now that the RegisterContext class doesn't require
a stack frame, we patched a memory leak where a StackFrame object was being
created and leaked.

Made the RegisterContext class not have a pointer to a StackFrame object as
one register context class can be used for N inlined stack frames so there is
not a 1 - 1 mapping. Updates the ExecutionContextScope part of the
RegisterContext class to never return a stack frame to indicate this when it
is asked to recreate the execution context. Now register contexts point to the
concrete frame using a concrete frame index. Concrete frames are all of the
frames that are actually formed on the stack of a thread. These concrete frames
can be turned into one or more user visible frames due to inlining. Each
inlined stack frame has the exact same register context (shared via shared
pointers) as any parent inlined stack frames all the way up to the concrete
frame itself.

So now the stack frames and the register contexts should behave much better.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@122976 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
f3d0b0c8081691128626eb496fdfcbf8ae54c1de 27-Oct-2010 Greg Clayton <gclayton@apple.com> Updated the lldb_private::Flags class to have better method names and made
all of the calls inlined in the header file for better performance.

Fixed the summary for C string types (array of chars (with any combo if
modifiers), and pointers to chars) work in all cases.

Fixed an issue where a forward declaration to a clang type could cause itself
to resolve itself more than once if, during the resolving of the type itself
it caused something to try and resolve itself again. We now remove the clang
type from the forward declaration map in the DWARF parser when we start to
resolve it and avoid this additional call. This should stop any duplicate
members from appearing and throwing all the alignment of structs, unions and
classes.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@117437 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
4912f39e324deab9fa5d2b4e114e017467c6b798 08-Oct-2010 Greg Clayton <gclayton@apple.com> Make sure to lock down the sequence mutex and select the thread we want when read or write all registers.

git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@115992 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
3a4ea24572fad1e22525f8efb718d49d41e30398 10-Sep-2010 Jason Molenda <jmolenda@apple.com> The first part of an lldb native stack unwinder.

The Unwind and RegisterContext subclasses still need
to be finished; none of this code is used by lldb at
this point (unless you call into it by hand).

The ObjectFile class now has an UnwindTable object.

The UnwindTable object has a series of FuncUnwinders
objects (Function Unwinders) -- one for each function
in that ObjectFile we've backtraced through during this
debug session.

The FuncUnwinders object has a few different UnwindPlans.
UnwindPlans are a generic way of describing how to find
the canonical address of a given function's stack frame
(the CFA idea from DWARF/eh_frame) and how to restore the
caller frame's register values, if they have been saved
by this function.

UnwindPlans are created from different sources. One source is the
eh_frame exception handling information generated by the compiler
for unwinding an exception throw. Another source is an assembly
language inspection class (UnwindAssemblyProfiler, uses the Plugin
architecture) which looks at the instructions in the funciton
prologue and describes the stack movements/register saves that are
done.

Two additional types of UnwindPlans that are worth noting are
the "fast" stack UnwindPlan which is useful for making a first
pass over a thread's stack, determining how many stack frames there
are and retrieving the pc and CFA values for each frame (enough
to create StackFrameIDs). Only a minimal set of registers is
recovered during a fast stack walk.

The final UnwindPlan is an architectural default unwind plan.
These are provided by the ArchDefaultUnwindPlan class (which uses
the plugin architecture). When no symbol/function address range can
be found for a given pc value -- when we have no eh_frame information
and when we don't have a start address so we can't examine the assembly
language instrucitons -- we have to make a best guess about how to
unwind. That's when we use the architectural default UnwindPlan.
On x86_64, this would be to assume that rbp is used as a stack pointer
and we can use that to find the caller's frame pointer and pc value.
It's a last-ditch best guess about how to unwind out of a frame.

There are heuristics about when to use one UnwindPlan versues the other --
this will all happen in the still-begin-written UnwindLLDB subclass of
Unwind which runs the UnwindPlans.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@113581 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
53d68e749f0715691a95f23e9490d97e484b15da 21-Jul-2010 Greg Clayton <gclayton@apple.com> Remove use of STL collection class use of the "data()" method since it isn't
part of C++'98. Most of these were "std::vector<T>::data()" and
"std::string::data()".



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@108957 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
54e7afa84d945f9137f9372ecde432f9e1a702fc 09-Jul-2010 Greg Clayton <gclayton@apple.com> Merged Eli Friedman's linux build changes where he added Makefile files that
enabled LLVM make style building and made this compile LLDB on Mac OS X. We
can now iterate on this to make the build work on both linux and macosx.



git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@108009 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
3ae93402b2df4dbd6268bb9ebd190c381fc2970b 21-Jun-2010 Benjamin Kramer <benny.kra@googlemail.com> Initialize member so GDBRemoteRegisterContext::ReadRegisterBytes doesn't rely on
an unitialized variable.

valgrind_errors -= 1;


git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@106418 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteRegisterContext.cpp
24943d2ee8bfaa7cf5893e4709143924157a5c1e 08-Jun-2010 Chris Lattner <sabre@nondot.org> Initial checkin of lldb code from internal Apple repo.


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