| 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/GDBRemoteCommunicationServer.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/GDBRemoteCommunicationServer.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/GDBRemoteCommunicationServer.cpp
|
| 6adf91fd49de2a5463da39b071e9837741367486 |
|
14-Jul-2012 |
Enrico Granata <egranata@apple.com> |
Fixing a buildbot issue in GDBRemoteCommunicationServer due to an undefined constant in latest commit
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@160208 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.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/GDBRemoteCommunicationServer.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/GDBRemoteCommunicationServer.cpp
|
| 8c1b38294f9b33d14d10ace3f7bd50fbbe9923d9 |
|
03-Apr-2012 |
Bill Wendling <isanbard@gmail.com> |
Use integers instead of NULL.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@153941 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.cpp
|
| 95ec1688db0efe51509ad9356052f5004d8856e0 |
|
06-Mar-2012 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/10840355>
Fixed STDERR to not be opened as readable. Also cleaned up some of the code that implemented the file actions as some of the code was using the wrong variables, they now use the right ones (in for stdin, out for stdout, err for stderr).
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@152102 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.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/GDBRemoteCommunicationServer.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/GDBRemoteCommunicationServer.cpp
|
| f7a9b14c2c02d2fa9fad586c19f29d77533fcc09 |
|
15-Jul-2011 |
Enrico Granata <granata.enrico@gmail.com> |
Python summary strings:
- you can use a Python script to write a summary string for data-types, in one of
three ways:
-P option and typing the script a line at a time
-s option and passing a one-line Python script
-F option and passing the name of a Python function
these options all work for the "type summary add" command
your Python code (if provided through -P or -s) is wrapped in a function
that accepts two parameters: valobj (a ValueObject) and dict (an LLDB
internal dictionary object). if you use -F and give a function name,
you're expected to define the function on your own and with the right
prototype. your function, however defined, must return a Python string
- test case for the Python summary feature
- a few quirks:
Python summaries cannot have names, and cannot use regex as type names
both issues will be fixed ASAP
major redesign of type summary code:
- type summary working with strings and type summary working with Python code
are two classes, with a common base class SummaryFormat
- SummaryFormat classes now are able to actively format objects rather than
just aggregating data
- cleaner code to print descriptions for summaries
the public API now exports a method to easily navigate a ValueObject hierarchy
New InputReaderEZ and PriorityPointerPair classes
Several minor fixes and improvements
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@135238 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Process/gdb-remote/GDBRemoteCommunicationServer.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/GDBRemoteCommunicationServer.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/GDBRemoteCommunicationServer.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/GDBRemoteCommunicationServer.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/GDBRemoteCommunicationServer.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/GDBRemoteCommunicationServer.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/GDBRemoteCommunicationServer.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/GDBRemoteCommunicationServer.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/GDBRemoteCommunicationServer.cpp
|