plug-ins are add on plug-ins for the lldb_private::Process class that can add
thread contexts that are read from memory. It is common in kernels to have
a lot of threads that are not currently executing on any cores (JTAG debugging
also follows this sort of thing) and are context switched out whose state is
stored in memory data structures. Clients can now subclass the OperatingSystem
plug-ins and then make sure their Create functions correcltly only enable
themselves when the right binary/target triple are being debugged. The
operating system plug-ins get a chance to attach themselves to processes just
after launching or attaching and are given a lldb_private::Process object
pointer which can be inspected to see if the main executable, target triple,
or any shared libraries match a case where the OS plug-in should be used.
Currently the OS plug-ins can create new threads, define the register contexts
for these threads (which can all be different if desired), and populate and
manage the thread info (stop reason, registers in the register context) as
the debug session goes on.
llvm-svn: 138228
This is helping us track down some extra references to ModuleSP objects that
are causing things to get kept around for too long.
Added a module pointer accessor to target and change a lot of code to use
it where it would be more efficient.
"taret delete" can now specify "--clean=1" which will cleanup the global module
list for any orphaned module in the shared module cache which can save memory
and also help track down module reference leaks like we have now.
llvm-svn: 137294
10 second timeout zone. When launching we increase the
timeout to 10 seconds to ensure we have time to launch a
process, and then set it back.
llvm-svn: 137256
ability to dump more information about modules in "target modules list". We
can now dump the shared pointer reference count for modules, the pointer to
the module itself (in case performance tools can help track down who has
references to said pointer), and the modification time.
Added "target delete [target-idx ...]" to be able to delete targets when they
are no longer needed. This will help track down memory usage issues and help
to resolve when module ref counts keep getting incremented. If the command gets
no arguments, the currently selected target will be deleted. If any arguments
are given, they must all be valid target indexes (use the "target list"
command to get the current target indexes).
Took care of a bunch of "no newline at end of file" warnings.
TimeValue objects can now dump their time to a lldb_private::Stream object.
Modified the "target modules list --global" command to not error out if there
are no targets since it doesn't require a target.
Fixed an issue in the MacOSX DYLD dynamic loader plug-in where if a shared
library was updated on disk, we would keep using the older one, even if it was
updated.
Don't allow the ModuleList::GetSharedModule(...) to return an empty module.
Previously we could specify a valid path on disc to a module, and specify an
architecture that wasn't contained in that module and get a shared pointer to
a module that wouldn't be able to return an object file or a symbol file. We
now make sure an object file can be extracted prior to adding the shared pointer
to the module to get added to the shared list.
llvm-svn: 137196
method so process plug-ins that are requested by name can answer yes when
asked if they can debug a target that might not have any file in the target.
Modified the ConnectionFileDescriptor to have both a read and a write file
descriptor. This allows us to support UDP, and eventually will allow us to
support pipes. The ConnectionFileDescriptor class also has a file descriptor
type for each of the read and write file decriptors so we can use the correct
read/recv/recvfrom call when reading, or write/send/sendto for writing.
Finished up an initial implementation of UDP where you can use the "udp://"
URL to specify a host and port to connect to:
(lldb) process connect --plugin kdp-remote udp://host:41139
This will cause a ConnectionFileDescriptor to be created that can send UDP
packets to "host:41139", and it will also bind to a localhost port that can
be given out to receive the connectionless UDP reply.
Added the ability to get to the IPv4/IPv6 socket port number from a
ConnectionFileDescriptor instance if either file descriptor is a socket.
The ProcessKDP can now successfully connect to a remote kernel and detach
using the above "processs connect" command!!! So far we have the following
packets working:
KDP_CONNECT
KDP_DISCONNECT
KDP_HOSTINFO
KDP_VERSION
KDP_REATTACH
Now that the packets are working, adding new packets will go very quickly.
llvm-svn: 135363
connected process connection.
Also added support for more kinds of continue packet when multiple threads
need to continue where some want to continue with signals.
llvm-svn: 133785
and set the address as an opcode address or as a callable address. This is
needed in various places in the thread plans to make sure that addresses that
might be found in symbols or runtime might already have extra bits set (ARM/Thumb).
The new functions are:
bool
Address::SetCallableLoadAddress (lldb::addr_t load_addr, Target *target);
bool
Address::SetOpcodeLoadAddress (lldb::addr_t load_addr, Target *target);
SetCallableLoadAddress will initialize a section offset address if it can,
and if so it might possibly set some bits in the address to make the address
callable (bit zero might get set for ARM for Thumb functions).
SetOpcodeLoadAddress will initialize a section offset address using the
specified target and it will strip any special address bits if needed
depending on the target.
Fixed the ABIMacOSX_arm::GetArgumentValues() function to require arguments
1-4 to be in the needed registers (previously this would incorrectly fallback
to the stack) and return false if unable to get the register values. The
function was also modified to first look for the generic argument registers
and then fall back to finding the registers by name.
Fixed the objective trampoline handler to use the new Address::SetOpcodeLoadAddress
function when needed to avoid address mismatches when trying to complete
steps into objective C methods. Make similar fixes inside the
AppleThreadPlanStepThroughObjCTrampoline::ShouldStop() function.
Modified ProcessGDBRemote::BuildDynamicRegisterInfo(...) to be able to deal with
the new generic argument registers.
Modified RNBRemote::HandlePacket_qRegisterInfo() to handle the new generic
argument registers on the debugserver side.
Modified DNBArchMachARM::NumSupportedHardwareBreakpoints() to be able to
detect how many hardware breakpoint registers there are using a darwin sysctl.
Did the same for hardware watchpoints in
DNBArchMachARM::NumSupportedHardwareWatchpoints().
llvm-svn: 131834
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.
llvm-svn: 131454
over when running JITed expressions. The allocated memory cache will cache
allocate memory a page at a time for each permission combination and divvy up
the memory and hand it out in 16 byte increments.
llvm-svn: 131453
thread plan. In order to get the return value, you can call:
void
ThreadPlanCallFunction::RequestReturnValue (lldb::ValueSP &return_value_sp);
This registers a shared pointer to a return value that will get filled in if
everything goes well. After the thread plan is run the return value will be
extracted for you.
Added an ifdef to be able to switch between the LLVM MCJIT and the standand JIT.
We currently have the standard JIT selected because we have some work to do to
get the MCJIT fuctioning properly.
Added the ability to call functions with 6 argument in the x86_64 ABI.
Added the ability for GDBRemoteCommunicationClient to detect if the allocate
and deallocate memory packets are supported and to not call allocate memory
("_M") or deallocate ("_m") if we find they aren't supported.
Modified the ProcessGDBRemote::DoAllocateMemory(...) and ProcessGDBRemote::DoDeallocateMemory(...)
to be able to deal with the allocate and deallocate memory packets not being
supported. If they are not supported, ProcessGDBRemote will switch to calling
"mmap" and "munmap" to allocate and deallocate memory instead using our
trivial function call support.
Modified the "void ProcessGDBRemote::DidLaunchOrAttach()" to correctly ignore
the qHostInfo triple information if any was specified in the target. Currently
if the target only specifies an architecture when creating the target:
(lldb) target create --arch i386 a.out
Then the vendor, os and environemnt will be adopted by the target.
If the target was created with any triple that specifies more than the arch:
(lldb) target create --arch i386-unknown-unknown a.out
Then the target will maintain its triple and not adopt any new values. This
can be used to help force bare board debugging where the dynamic loader for
static files will get used and users can then use "target modules load ..."
to set addressses for any files that are desired.
Added back some convenience functions to the lldb_private::RegisterContext class
for writing registers with unsigned values. Also made all RegisterContext
constructors explicit to make sure we know when an integer is being converted
to a RegisterValue.
llvm-svn: 131370
a new "QLaunchArch:<arch-name>" where <arch-name> is the architecture name.
This allows us to remotely launch a debugserver and then set the architecture
for the binary we will launch.
llvm-svn: 131064
interface.
Added a quick way to set the platform though the SBDebugger interface. I will
actually an a SBPlatform support soon, but for now this will do.
ConnectionFileDescriptor can be passed a url formatted as: "fd://<fd>" where
<fd> is a file descriptor in the current process. This is handy if you have
services, deamons, or other tools that can spawn processes and give you a
file handle.
llvm-svn: 130565
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.
llvm-svn: 129351
event.
Modified the ProcessInfo structure to contain all process arguments. Using the
new function calls on MacOSX allows us to see the full process name, not just
the first 16 characters.
Added a new platform command: "platform process info <pid> [<pid> <pid> ...]"
that can be used to get detailed information for a process including all
arguments, user and group info and more.
llvm-svn: 128694
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;
llvm-svn: 128563
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.
llvm-svn: 128123
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.
llvm-svn: 128070
platform status -- gets status information for the selected platform
platform create <platform-name> -- creates a new instance of a remote platform
platform list -- list all available platforms
platform select -- select a platform instance as the current platform (not working yet)
When using "platform create" it will create a remote platform and make it the
selected platform. For instances for iPhone OS debugging on Mac OS X one can
do:
(lldb) platform create remote-ios --sdk-version=4.0
Remote platform: iOS platform
SDK version: 4.0
SDK path: "/Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0"
Not connected to a remote device.
(lldb) file ~/Documents/a.out
Current executable set to '~/Documents/a.out' (armv6).
(lldb) image list
[ 0] /Volumes/work/gclayton/Documents/devb/attach/a.out
[ 1] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/dyld
[ 2] /Developer/Platforms/iPhoneOS.platform/DeviceSupport/4.0/Symbols/usr/lib/libSystem.B.dylib
Note that this is all happening prior to running _or_ connecting to a remote
platform. Once connected to a remote platform the OS version might change which
means we will need to update our dependecies. Also once we run, we will need
to match up the actualy binaries with the actualy UUID's to files in the
SDK, or download and cache them locally.
This is just the start of the remote platforms, but this modification is the
first iteration in getting the platforms really doing something.
llvm-svn: 127934
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.
llvm-svn: 127392
an interface to a local or remote debugging platform. By default each host OS
that supports LLDB should be registering a "default" platform that will be
used unless a new platform is selected. Platforms are responsible for things
such as:
- getting process information by name or by processs ID
- finding platform files. This is useful for remote debugging where there is
an SDK with files that might already or need to be cached for debug access.
- getting a list of platform supported architectures in the exact order they
should be selected. This helps the native x86 platform on MacOSX select the
correct x86_64/i386 slice from universal binaries.
- Connect to remote platforms for remote debugging
- Resolving an executable including finding an executable inside platform
specific bundles (macosx uses .app bundles that contain files) and also
selecting the appropriate slice of universal files for a given platform.
So by default there is always a local platform, but remote platforms can be
connected to. I will soon be adding a new "platform" command that will support
the following commands:
(lldb) platform connect --name machine1 macosx connect://host:port
Connected to "machine1" platform.
(lldb) platform disconnect macosx
This allows LLDB to be well setup to do remote debugging and also once
connected process listing and finding for things like:
(lldb) process attach --name x<TAB>
The currently selected platform plug-in can now auto complete any available
processes that start with "x". The responsibilities for the platform plug-in
will soon grow and expand.
llvm-svn: 127286
anything in a SBSymbolContext filled in given an SBAddress:
SBSymbolContext
SBTarget::ResolveSymbolContextForAddress (const SBAddress& addr, uint32_t resolve_scope);
Also did a little cleanup on the ProcessGDBRemote stdio file handle
code.
llvm-svn: 126885
Modifed lldb_private::Process to be able to handle connecting to a remote
target that isn't running a process. This leaves lldb_private::Process in the
eStateConnected state from which we can then do an attach or launch.
Modified ProcessGDBRemote to be able to set stdin, stdout, stderr, working
dir, disable ASLR and a few other settings down by using new GDB remote
packets. This allows us to keep all of our current launch flags and settings
intact and still be able to communicate them over to the remote GDB server.
Previously these were being sent as arguments to the debugserver binary that
we were spawning. Also modified ProcessGDBRemote to handle losing connection
to the remote GDB server and always exit immediately. We do this by watching
the lldb_private::Communication event bit for the read thread exiting in the
ProcessGDBRemote async thread.
Added support for many of the new 'Q' packets for setting stdin, stdout,
stderr, working dir and disable ASLR to the GDBRemoteCommunication class for
easy accesss.
Modified debugserver for all of the new 'Q' packets and also made it so that
debugserver always exists if it loses connection with the remote debugger.
llvm-svn: 126444
of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up
doing was:
- Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics
the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple
to give us the machine type from llvm::Triple::ArchType.
- There is a new ArchSpec::Core definition which further qualifies the CPU
core we are dealing with into a single enumeration. If you need support for
a new Core and want to debug it in LLDB, it must be added to this list. In
the future we can allow for dynamic core registration, but for now it is
hard coded.
- The ArchSpec can now be initialized with a llvm::Triple or with a C string
that represents the triple (it can just be an arch still like "i386").
- The ArchSpec can still initialize itself with a architecture type -- mach-o
with cpu type and subtype, or ELF with e_machine + e_flags -- and this will
then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core.
The mach-o cpu type and subtype can be accessed using the getter functions:
uint32_t
ArchSpec::GetMachOCPUType () const;
uint32_t
ArchSpec::GetMachOCPUSubType () const;
But these functions are just converting out internal llvm::Triple::ArchSpec
+ ArchSpec::Core back into mach-o. Same goes for ELF.
All code has been updated to deal with the changes.
This should abstract us until later when the llvm::TargetSpec stuff gets
finalized and we can then adopt it.
llvm-svn: 126278
it should live and the lldb_private::Process takes care of managing the
auto pointer to the dynamic loader instance.
Also, now that the ArchSpec contains the target triple, we are able to
correctly set the Target architecture in DidLaunch/DidAttach in the subclasses,
and then the lldb_private::Process will find the dynamic loader plug-in
by letting the dynamic loader plug-ins inspect the arch/triple in the target.
So now the ProcessGDBRemote plug-in is another step closer to be purely
process/platform agnostic.
I updated the ProcessMacOSX and the ProcessLinux plug-ins accordingly.
llvm-svn: 125650
now, in addition to cpu type/subtype and architecture flavor, contains:
- byte order (big endian, little endian)
- address size in bytes
- llvm::Triple for true target triple support and for more powerful plug-in
selection.
llvm-svn: 125602
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.
llvm-svn: 125541
are supported by the remote GDB target. We can also now deal with the lack of
vCont support and send packets that the remote GDB stub can use. We also error
out of the continue if LLDB tries to do something too complex when vCont isn't
supported.
llvm-svn: 125433
(lldb) process connect <remote-url>
Currently when you specify a file with the file command it helps us to find
a process plug-in that is suitable for debugging. If you specify a file you
can rely upon this to find the correct debugger plug-in:
% lldb a.out
Current executable set to 'a.out' (x86_64).
(lldb) process connect connect://localhost:2345
...
If you don't specify a file, you will need to specify the plug-in name that
you wish to use:
% lldb
(lldb) process connect --plugin process.gdb-remote connect://localhost:2345
Other connection URL examples:
(lldb) process connect connect://localhost:2345
(lldb) process connect tcp://127.0.0.1
(lldb) process connect file:///dev/ttyS1
We are currently treating the "connect://host:port" as a way to do raw socket
connections. If there is a URL for this already, please let me know and we
will adopt it.
So now you can connect to a remote debug server with the ProcessGDBRemote
plug-in. After connection, it will ask for the pid info using the "qC" packet
and if it responds with a valid process ID, it will be equivalent to attaching.
If it response with an error or invalid process ID, the LLDB process will be
in a new state: eStateConnected. This allows us to then download a program or
specify the program to run (using the 'A' packet), or specify a process to
attach to (using the "vAttach" packets), or query info about the processes
that might be available.
llvm-svn: 124846
