| 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/Platform/gdb-server/PlatformRemoteGDBServer.cpp
|
| 0e191607adcb0ea8ebd06c278be648a7f5c0097f |
|
10-May-2013 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/13854277>
<rdar://problem/13594769>
Main changes in this patch include:
- cleanup plug-in interface and use ConstStrings for plug-in names
- Modfiied the BSD Archive plug-in to be able to pick out the correct .o file when .a files contain multiple .o files with the same name by using the timestamp
- Modified SymbolFileDWARFDebugMap to properly verify the timestamp on .o files it loads to ensure we don't load updated .o files and cause problems when debugging
The plug-in interface changes:
Modified the lldb_private::PluginInterface class that all plug-ins inherit from:
Changed:
virtual const char * GetPluginName() = 0;
To:
virtual ConstString GetPluginName() = 0;
Removed:
virtual const char * GetShortPluginName() = 0;
- Fixed up all plug-in to adhere to the new interface and to return lldb_private::ConstString values for the plug-in names.
- Fixed all plug-ins to return simple names with no prefixes. Some plug-ins had prefixes and most ones didn't, so now they all don't have prefixed names, just simple names like "linux", "gdb-remote", etc.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@181631 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp
|
| d891f9b872103235cfd2ed452c6f14a4394d9b3a |
|
05-Dec-2012 |
Daniel Malea <daniel.malea@intel.com> |
Fix Linux build warnings due to redefinition of macros:
- add new header lldb-python.h to be included before other system headers
- short term fix (eventually python dependencies must be cleaned up)
Patch by Matt Kopec!
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@169341 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp
|
| ed0a0fbd021e44727469d6fa20cc337c58bd04c3 |
|
18-Oct-2012 |
Greg Clayton <gclayton@apple.com> |
<rdar://problem/12462048>
<rdar://problem/12068650>
More fixes to how we handle paths that are used to create a target.
This modification centralizes the location where and how what the user specifies gets resolved. Prior to this fix, the TargetList::CreateTarget variants took a FileSpec object which meant everyone had the opportunity to resolve the path their own way. Now both CreateTarget variants take a "const char *use_exe_path" which allows the TargetList::CreateTarget to centralize where the resolving happens and "do the right thing".
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@166186 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp
|
| fac2e62f08719ba800a440b7ad0d5a55a26dc620 |
|
29-Sep-2012 |
Jason Molenda <jmolenda@apple.com> |
Add support for debugging KASLR kernels via kdp (the kernel being
loaded at a random offset).
To get the kernel's UUID and load address I need to send a kdp
packet so I had to implement the kernel relocation (and attempt to
find the kernel if none was provided to lldb already) in ProcessKDP
-- but this code really properly belongs in DynamicLoaderDarwinKernel.
I also had to add an optional Stream to ConnectRemote so
ProcessKDP::DoConnectRemote can print feedback about the remote kernel's
UUID, load address, and notify the user if we auto-loaded the kernel via
the UUID.
<rdar://problem/7714201>
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@164881 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.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/Platform/gdb-server/PlatformRemoteGDBServer.cpp
|
| b1db658333cdebca31a128be95e926d80c3c7796 |
|
20-Mar-2012 |
Greg Clayton <gclayton@apple.com> |
Platforms can now auto-select themselves if you specify a full target triple when doing a "target create" command.
Each platform now knows if it can handle an architecture and a platform can be found using an architecture. Each platform can look at the arch, vendor and OS and know if it should be used or not.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@153104 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp
|
| 9ce953807eb814a93b449dc243de4f7bf32c3115 |
|
14-Feb-2012 |
Greg Clayton <gclayton@apple.com> |
Full core file support has been added for mach-o core files.
Tracking modules down when you have a UUID and a path has been improved.
DynamicLoaderDarwinKernel no longer parses mach-o load commands and it
now uses the memory based modules now that we can load modules from memory.
Added a target setting named "target.exec-search-paths" which can be used
to supply a list of directories to use when trying to look for executables.
This allows one or more directories to be used when searching for modules
that may not exist in the SDK/PDK. The target automatically adds the directory
for the main executable to this list so this should help us in tracking down
shared libraries and other binaries.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@150426 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp
|
| 46c9a355af9b39db78c006b2a5cbf97d3c58d947 |
|
09-Feb-2012 |
Greg Clayton <gclayton@apple.com> |
First pass at mach-o core file support is in. It currently works for x86_64
user space programs. The core file support is implemented by making a process
plug-in that will dress up the threads and stack frames by using the core file
memory.
Added many default implementations for the lldb_private::Process functions so
that plug-ins like the ProcessMachCore don't need to override many many
functions only to have to return an error.
Added new virtual functions to the ObjectFile class for extracting the frozen
thread states that might be stored in object files. The default implementations
return no thread information, but any platforms that support core files that
contain frozen thread states (like mach-o) can make a module using the core
file and then extract the information. The object files can enumerate the
threads and also provide the register state for each thread. Since each object
file knows how the thread registers are stored, they are responsible for
creating a suitable register context that can be used by the core file threads.
Changed the process CreateInstace callbacks to return a shared pointer and
to also take an "const FileSpec *core_file" parameter to allow for core file
support. This will also allow for lldb_private::Process subclasses to be made
that could load crash logs. This should be possible on darwin where the crash
logs contain all of the stack frames for all of the threads, yet the crash
logs only contain the registers for the crashed thrad. It should also allow
some variables to be viewed for the thread that crashed.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@150154 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.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/Platform/gdb-server/PlatformRemoteGDBServer.cpp
|
| 2d9adb73af7520bec430e0585ca40467828e6ed1 |
|
12-Nov-2011 |
Greg Clayton <gclayton@apple.com> |
Added the ability to run a process in a shell on MacOSX currently when using
the --tty option. So you can now get shell expansion and file redirection:
(lldb) process launch --tty --shell -- *.jpg < in.txt > out.txt
Again, the "--tty" is mandatory for now until we hook this up to other
functions. The shell is also currently hard coded to "/bin/bash" and not the
"SHELL" variable. "/bin/tcsh" was causing problems which I need to dig into.
git-svn-id: https://llvm.org/svn/llvm-project/lldb/trunk@144443 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp
|
| 9c236733d43e6250c8a5671a438f4a2afeb9c0b2 |
|
26-Oct-2011 |
Greg Clayton <gclayton@apple.com> |
Cleaned up many error codes. For any who is filling in error strings into
lldb_private::Error objects the rules are:
- short strings that don't start with a capitol letter unless the name is a
class or anything else that is always capitolized
- no trailing newline character
- should be one line if possible
Implemented a first pass at adding "--gdb-format" support to anything that
accepts format with optional size/count.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@142999 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp
|
| 3e8c25f62f92145b6fb699b379cbfe72b1245d4a |
|
24-Sep-2011 |
Greg Clayton <gclayton@apple.com> |
Added to the public API to allow symbolication:
- New SBSection objects that are object file sections which can be accessed
through the SBModule classes. You can get the number of sections, get a
section at index, and find a section by name.
- SBSections can contain subsections (first find "__TEXT" on darwin, then
us the resulting SBSection to find "__text" sub section).
- Set load addresses for a SBSection in the SBTarget interface
- Set the load addresses of all SBSection in a SBModule in the SBTarget interface
- Add a new module the an existing target in the SBTarget interface
- Get a SBSection from a SBAddress object
This should get us a lot closer to being able to symbolicate using LLDB through
the public API.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@140437 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.cpp
|
| 5e342f50b42b265d8568e1c926328858e74b2c0a |
|
14-Apr-2011 |
Greg Clayton <gclayton@apple.com> |
Added auto completion for architecture names and for platforms.
Modified the OptionGroupOptions to be able to specify only some of the options
that should be appended by using the usage_mask in the group defintions and
also provided a way to remap them to a new usage mask after the copy. This
allows options to be re-used and also targetted for specific option groups.
Modfied the CommandArgumentType to have a new eArgTypePlatform enumeration.
Taught the option parser to be able to automatically use the appropriate
auto completion for a given options if nothing is explicitly specified
in the option definition. So you don't have to specify it in the option
definition tables.
Renamed the default host platform name to "host", and the default platform
hostname to be "localhost".
Modified the "file" and "platform select" commands to make sure all options
and args are good prior to creating a new platform. Also defer the computation
of the architecture in the file command until all options are parsed and the
platform has either not been specified or reset to a new value to avoid
computing the arch more than once.
Switch the PluginManager code over to using llvm::StringRef for string
comparisons and got rid of all the AccessorXXX functions in lieu of the newer
mutex + collection singleton accessors.
git-svn-id: https://llvm.org/svn/llvm-project/llvdb/trunk@129483 91177308-0d34-0410-b5e6-96231b3b80d8
/external/lldb/source/Plugins/Platform/gdb-server/PlatformRemoteGDBServer.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/Platform/gdb-server/PlatformRemoteGDBServer.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/Platform/gdb-server/PlatformRemoteGDBServer.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/Platform/gdb-server/PlatformRemoteGDBServer.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/Platform/gdb-server/PlatformRemoteGDBServer.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/Platform/gdb-server/PlatformRemoteGDBServer.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/Platform/gdb-server/PlatformRemoteGDBServer.cpp
|