maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lldb/source/Host/macosx/Host.mm

1993 lines
66 KiB
Plaintext
Raw Normal View History

Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//===-- Host.mm -------------------------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
Patch from Jay Cornwall that modifies the LLDB "Host" layer to reuse more code between linux, darwin and BSD. llvm-svn: 113263
2010-09-08 04:11:56 +08:00
#include "lldb/Host/Host.h"
Added a new Host call to find LLDB related paths: static bool Host::GetLLDBPath (lldb::PathType path_type, FileSpec &file_spec); This will fill in "file_spec" with an appropriate path that is appropriate for the current Host OS. MacOSX will return paths within the LLDB.framework, and other unixes will return the paths they want. The current PathType enums are: typedef enum PathType { ePathTypeLLDBShlibDir, // The directory where the lldb.so (unix) or LLDB mach-o file in LLDB.framework (MacOSX) exists ePathTypeSupportExecutableDir, // Find LLDB support executable directory (debugserver, etc) ePathTypeHeaderDir, // Find LLDB header file directory ePathTypePythonDir // Find Python modules (PYTHONPATH) directory } PathType; All places that were finding executables are and python paths are now updated to use this Host call. Added another new host call to launch the inferior in a terminal. This ability will be very host specific and doesn't need to be supported on all systems. MacOSX currently will create a new .command file and tell Terminal.app to open the .command file. It also uses the new "darwin-debug" app which is a small app that uses posix to exec (no fork) and stop at the entry point of the program. The GDB remote plug-in is almost able launch a process and attach to it, it currently will spawn the process, but it won't attach to it just yet. This will let LLDB not have to share the terminal with another process and a new terminal window will pop up when you launch. This won't get hooked up until we work out all of the kinks. The new Host function is: static lldb::pid_t Host::LaunchInNewTerminal ( const char **argv, // argv[0] is executable const char **envp, const ArchSpec *arch_spec, bool stop_at_entry, bool disable_aslr); Cleaned up FileSpec::GetPath to not use strncpy() as it was always zero filling the entire path buffer. Fixed an issue with the dynamic checker function where I missed a '$' prefix that should have been added. llvm-svn: 116690
2010-10-18 06:03:32 +08:00
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
#include <AvailabilityMacros.h>
#if !defined(MAC_OS_X_VERSION_10_7) || MAC_OS_X_VERSION_MAX_ALLOWED < MAC_OS_X_VERSION_10_7
Use a new define, NO_XPC_SERVICES, to indicate that macosx/Host.mm shouldn't compile any of the XPC support code. Update macosx/Host.mm to use that define. Add a LLDB_DISABLE_PYTHON ifdef block around a new function in Core/FormatManager.cpp. <rdar://problem/10942125> llvm-svn: 152293
2012-03-08 12:03:25 +08:00
#define NO_XPC_SERVICES 1
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
#endif
Use a new define, NO_XPC_SERVICES, to indicate that macosx/Host.mm shouldn't compile any of the XPC support code. Update macosx/Host.mm to use that define. Add a LLDB_DISABLE_PYTHON ifdef block around a new function in Core/FormatManager.cpp. <rdar://problem/10942125> llvm-svn: 152293
2012-03-08 12:03:25 +08:00
#if !defined(NO_XPC_SERVICES)
<rdar://problem/9886712> Added a dedicated platform for the iOS simulator. This helps us to find the correct files for a simulator binary before running and helps us select the right arch (i386 only) for files when we load them. llvm-svn: 151436
2012-02-25 14:56:35 +08:00
#define __XPC_PRIVATE_H__
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
#include <xpc/xpc.h>
Use the path to the header file. Use an integer instead of NULL. And get rid of a superfluous 'default' label. llvm-svn: 153943
2012-04-03 15:51:16 +08:00
#include "launcherXPCService/LauncherXPCService.h"
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
#endif
Fix some names in the wake of my Mach-O changes to LLVM. llvm-svn: 189317
2013-08-27 13:04:57 +08:00
#include "llvm/Support/Host.h"
Added code in the Host layer that can report system log messages so that we don't have "fprintf (stderr, ...)" calls sprinkled everywhere. Changed all needed locations over to using this. For non-darwin, we log to stderr only. On darwin, we log to stderr _and_ to ASL (Apple System Log facility). This will allow GUI apps to have a place for these error and warning messages to go, and also allows the command line apps to log directly to the terminal. llvm-svn: 147596
2012-01-05 11:57:59 +08:00
#include <asl.h>
Added the ability for a process to inherit the current host environment. This was done as an settings variable in the process for now. We will eventually move all environment stuff over to the target, but we will leave it with the process for now. The default setting is for a process to inherit the host environment. This can be disabled by setting the "inherit-env" setting to false in the process. llvm-svn: 120862
2010-12-04 08:10:17 +08:00
#include <crt_externs.h>
Fixed a race condition that could cause ProcessGDBRemote::DoResume() to return an error saying the resume timed out. Previously the thread that was trying to resume the process would eventually call ProcessGDBRemote::DoResume() which would broadcast an event over to the async GDB remote thread which would sent the continue packet to the remote gdb server. Right after this was sent, it would set a predicate boolean value (protected by a mutex and condition) and then the thread that issued the ProcessGDBRemote::DoResume() would then wait for that condition variable to be set. If the async gdb thread was too quick though, the predicate boolean value could have been set to true and back to false by the time the thread that issued the ProcessGDBRemote::DoResume() checks the boolean value. So we can't use the predicate value as a handshake. I have changed the code over to using a Event by having the GDB remote communication object post an event: GDBRemoteCommunication::eBroadcastBitRunPacketSent This allows reliable handshaking between the two threads and avoids the erroneous ProcessGDBRemote::DoResume() errors. Added a host backtrace service to allow in process backtraces when trying to track down tricky issues. I need to see if LLVM has any backtracing abilities abstracted in it already, and if so, use that, but I needed something ASAP for the current issue I was working on. The static function is: void Host::Backtrace (Stream &strm, uint32_t max_frames); And it will backtrace at most "max_frames" frames for the current thread and can be used with any of the Stream subclasses for logging. llvm-svn: 120793
2010-12-03 14:02:24 +08:00
#include <execinfo.h>
Added real user/group id, effective user/group id, and parent process ID to the ProcessInfo. llvm-svn: 128023
2011-03-22 05:25:07 +08:00
#include <grp.h>
Fixed all known race conditions with starting a process in a new terminal. We now spawn a thread to accept a unix socket connection from the inferior when it spawns in the terminal, then we launch the process, then we get the pid back through the unix socket, and then wait for it to SIGSTOP. darwin-debug now clears the terminal screen and prints out the program and arguments that are about to be launched. llvm-svn: 116841
2010-10-20 02:15:50 +08:00
#include <libproc.h>
Added real user/group id, effective user/group id, and parent process ID to the ProcessInfo. llvm-svn: 128023
2011-03-22 05:25:07 +08:00
#include <pwd.h>
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
#include <spawn.h>
Fixed a race condition that could cause ProcessGDBRemote::DoResume() to return an error saying the resume timed out. Previously the thread that was trying to resume the process would eventually call ProcessGDBRemote::DoResume() which would broadcast an event over to the async GDB remote thread which would sent the continue packet to the remote gdb server. Right after this was sent, it would set a predicate boolean value (protected by a mutex and condition) and then the thread that issued the ProcessGDBRemote::DoResume() would then wait for that condition variable to be set. If the async gdb thread was too quick though, the predicate boolean value could have been set to true and back to false by the time the thread that issued the ProcessGDBRemote::DoResume() checks the boolean value. So we can't use the predicate value as a handshake. I have changed the code over to using a Event by having the GDB remote communication object post an event: GDBRemoteCommunication::eBroadcastBitRunPacketSent This allows reliable handshaking between the two threads and avoids the erroneous ProcessGDBRemote::DoResume() errors. Added a host backtrace service to allow in process backtraces when trying to track down tricky issues. I need to see if LLVM has any backtracing abilities abstracted in it already, and if so, use that, but I needed something ASAP for the current issue I was working on. The static function is: void Host::Backtrace (Stream &strm, uint32_t max_frames); And it will backtrace at most "max_frames" frames for the current thread and can be used with any of the Stream subclasses for logging. llvm-svn: 120793
2010-12-03 14:02:24 +08:00
#include <stdio.h>
Fixed all known race conditions with starting a process in a new terminal. We now spawn a thread to accept a unix socket connection from the inferior when it spawns in the terminal, then we launch the process, then we get the pid back through the unix socket, and then wait for it to SIGSTOP. darwin-debug now clears the terminal screen and prints out the program and arguments that are about to be launched. llvm-svn: 116841
2010-10-20 02:15:50 +08:00
#include <sys/proc.h>
Added a new Host call to find LLDB related paths: static bool Host::GetLLDBPath (lldb::PathType path_type, FileSpec &file_spec); This will fill in "file_spec" with an appropriate path that is appropriate for the current Host OS. MacOSX will return paths within the LLDB.framework, and other unixes will return the paths they want. The current PathType enums are: typedef enum PathType { ePathTypeLLDBShlibDir, // The directory where the lldb.so (unix) or LLDB mach-o file in LLDB.framework (MacOSX) exists ePathTypeSupportExecutableDir, // Find LLDB support executable directory (debugserver, etc) ePathTypeHeaderDir, // Find LLDB header file directory ePathTypePythonDir // Find Python modules (PYTHONPATH) directory } PathType; All places that were finding executables are and python paths are now updated to use this Host call. Added another new host call to launch the inferior in a terminal. This ability will be very host specific and doesn't need to be supported on all systems. MacOSX currently will create a new .command file and tell Terminal.app to open the .command file. It also uses the new "darwin-debug" app which is a small app that uses posix to exec (no fork) and stop at the entry point of the program. The GDB remote plug-in is almost able launch a process and attach to it, it currently will spawn the process, but it won't attach to it just yet. This will let LLDB not have to share the terminal with another process and a new terminal window will pop up when you launch. This won't get hooked up until we work out all of the kinks. The new Host function is: static lldb::pid_t Host::LaunchInNewTerminal ( const char **argv, // argv[0] is executable const char **envp, const ArchSpec *arch_spec, bool stop_at_entry, bool disable_aslr); Cleaned up FileSpec::GetPath to not use strncpy() as it was always zero filling the entire path buffer. Fixed an issue with the dynamic checker function where I missed a '$' prefix that should have been added. llvm-svn: 116690
2010-10-18 06:03:32 +08:00
#include <sys/stat.h>
Added real user/group id, effective user/group id, and parent process ID to the ProcessInfo. llvm-svn: 128023
2011-03-22 05:25:07 +08:00
#include <sys/sysctl.h>
Fixed all known race conditions with starting a process in a new terminal. We now spawn a thread to accept a unix socket connection from the inferior when it spawns in the terminal, then we launch the process, then we get the pid back through the unix socket, and then wait for it to SIGSTOP. darwin-debug now clears the terminal screen and prints out the program and arguments that are about to be launched. llvm-svn: 116841
2010-10-20 02:15:50 +08:00
#include <sys/types.h>
Fixed a race condition that could cause ProcessGDBRemote::DoResume() to return an error saying the resume timed out. Previously the thread that was trying to resume the process would eventually call ProcessGDBRemote::DoResume() which would broadcast an event over to the async GDB remote thread which would sent the continue packet to the remote gdb server. Right after this was sent, it would set a predicate boolean value (protected by a mutex and condition) and then the thread that issued the ProcessGDBRemote::DoResume() would then wait for that condition variable to be set. If the async gdb thread was too quick though, the predicate boolean value could have been set to true and back to false by the time the thread that issued the ProcessGDBRemote::DoResume() checks the boolean value. So we can't use the predicate value as a handshake. I have changed the code over to using a Event by having the GDB remote communication object post an event: GDBRemoteCommunication::eBroadcastBitRunPacketSent This allows reliable handshaking between the two threads and avoids the erroneous ProcessGDBRemote::DoResume() errors. Added a host backtrace service to allow in process backtraces when trying to track down tricky issues. I need to see if LLVM has any backtracing abilities abstracted in it already, and if so, use that, but I needed something ASAP for the current issue I was working on. The static function is: void Host::Backtrace (Stream &strm, uint32_t max_frames); And it will backtrace at most "max_frames" frames for the current thread and can be used with any of the Stream subclasses for logging. llvm-svn: 120793
2010-12-03 14:02:24 +08:00
#include <unistd.h>
Added a new Host call to find LLDB related paths: static bool Host::GetLLDBPath (lldb::PathType path_type, FileSpec &file_spec); This will fill in "file_spec" with an appropriate path that is appropriate for the current Host OS. MacOSX will return paths within the LLDB.framework, and other unixes will return the paths they want. The current PathType enums are: typedef enum PathType { ePathTypeLLDBShlibDir, // The directory where the lldb.so (unix) or LLDB mach-o file in LLDB.framework (MacOSX) exists ePathTypeSupportExecutableDir, // Find LLDB support executable directory (debugserver, etc) ePathTypeHeaderDir, // Find LLDB header file directory ePathTypePythonDir // Find Python modules (PYTHONPATH) directory } PathType; All places that were finding executables are and python paths are now updated to use this Host call. Added another new host call to launch the inferior in a terminal. This ability will be very host specific and doesn't need to be supported on all systems. MacOSX currently will create a new .command file and tell Terminal.app to open the .command file. It also uses the new "darwin-debug" app which is a small app that uses posix to exec (no fork) and stop at the entry point of the program. The GDB remote plug-in is almost able launch a process and attach to it, it currently will spawn the process, but it won't attach to it just yet. This will let LLDB not have to share the terminal with another process and a new terminal window will pop up when you launch. This won't get hooked up until we work out all of the kinks. The new Host function is: static lldb::pid_t Host::LaunchInNewTerminal ( const char **argv, // argv[0] is executable const char **envp, const ArchSpec *arch_spec, bool stop_at_entry, bool disable_aslr); Cleaned up FileSpec::GetPath to not use strncpy() as it was always zero filling the entire path buffer. Fixed an issue with the dynamic checker function where I missed a '$' prefix that should have been added. llvm-svn: 116690
2010-10-18 06:03:32 +08:00
#include "lldb/Core/ArchSpec.h"
Stop the driver from handling SIGPIPE in case we communicate with stale sockets so the driver doesn't just crash. Added support for connecting to named sockets (unix IPC sockets) in ConnectionFileDescriptor. Modified the Host::LaunchInNewTerminal() for MacOSX to return the process ID of the inferior process instead of the process ID of the Terminal.app. This was done by modifying the "darwin-debug" executable to connect to lldb through a named unix socket which is passed down as an argument. This allows a quick handshake between "lldb" and "darwin-debug" so we can get the process ID of the inferior and then attach by process ID and avoid attaching to the inferior by process name since there could be more than one process with that name. This still has possible race conditions, those will be fixed in the near future. This fixes the SIGPIPE issues that were sometimes being seen when task_for_pid was failing. llvm-svn: 116792
2010-10-19 11:25:40 +08:00
#include "lldb/Core/Communication.h"
#include "lldb/Core/ConnectionFileDescriptor.h"
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
#include "lldb/Core/DataExtractor.h"
Patch from Jay Cornwall that modifies the LLDB "Host" layer to reuse more code between linux, darwin and BSD. llvm-svn: 113263
2010-09-08 04:11:56 +08:00
#include "lldb/Core/Log.h"
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
#include "lldb/Core/Module.h"
Added a new Host call to find LLDB related paths: static bool Host::GetLLDBPath (lldb::PathType path_type, FileSpec &file_spec); This will fill in "file_spec" with an appropriate path that is appropriate for the current Host OS. MacOSX will return paths within the LLDB.framework, and other unixes will return the paths they want. The current PathType enums are: typedef enum PathType { ePathTypeLLDBShlibDir, // The directory where the lldb.so (unix) or LLDB mach-o file in LLDB.framework (MacOSX) exists ePathTypeSupportExecutableDir, // Find LLDB support executable directory (debugserver, etc) ePathTypeHeaderDir, // Find LLDB header file directory ePathTypePythonDir // Find Python modules (PYTHONPATH) directory } PathType; All places that were finding executables are and python paths are now updated to use this Host call. Added another new host call to launch the inferior in a terminal. This ability will be very host specific and doesn't need to be supported on all systems. MacOSX currently will create a new .command file and tell Terminal.app to open the .command file. It also uses the new "darwin-debug" app which is a small app that uses posix to exec (no fork) and stop at the entry point of the program. The GDB remote plug-in is almost able launch a process and attach to it, it currently will spawn the process, but it won't attach to it just yet. This will let LLDB not have to share the terminal with another process and a new terminal window will pop up when you launch. This won't get hooked up until we work out all of the kinks. The new Host function is: static lldb::pid_t Host::LaunchInNewTerminal ( const char **argv, // argv[0] is executable const char **envp, const ArchSpec *arch_spec, bool stop_at_entry, bool disable_aslr); Cleaned up FileSpec::GetPath to not use strncpy() as it was always zero filling the entire path buffer. Fixed an issue with the dynamic checker function where I missed a '$' prefix that should have been added. llvm-svn: 116690
2010-10-18 06:03:32 +08:00
#include "lldb/Core/StreamFile.h"
#include "lldb/Core/StreamString.h"
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
#include "lldb/Host/Endian.h"
#include "lldb/Host/FileSpec.h"
#include "lldb/Target/Platform.h"
Added real user/group id, effective user/group id, and parent process ID to the ProcessInfo. llvm-svn: 128023
2011-03-22 05:25:07 +08:00
#include "lldb/Target/Process.h"
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
#include "lldb/Utility/CleanUp.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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. llvm-svn: 108009
2010-07-10 04:39:50 +08:00
#include "cfcpp/CFCBundle.h"
Added a new Host call to find LLDB related paths: static bool Host::GetLLDBPath (lldb::PathType path_type, FileSpec &file_spec); This will fill in "file_spec" with an appropriate path that is appropriate for the current Host OS. MacOSX will return paths within the LLDB.framework, and other unixes will return the paths they want. The current PathType enums are: typedef enum PathType { ePathTypeLLDBShlibDir, // The directory where the lldb.so (unix) or LLDB mach-o file in LLDB.framework (MacOSX) exists ePathTypeSupportExecutableDir, // Find LLDB support executable directory (debugserver, etc) ePathTypeHeaderDir, // Find LLDB header file directory ePathTypePythonDir // Find Python modules (PYTHONPATH) directory } PathType; All places that were finding executables are and python paths are now updated to use this Host call. Added another new host call to launch the inferior in a terminal. This ability will be very host specific and doesn't need to be supported on all systems. MacOSX currently will create a new .command file and tell Terminal.app to open the .command file. It also uses the new "darwin-debug" app which is a small app that uses posix to exec (no fork) and stop at the entry point of the program. The GDB remote plug-in is almost able launch a process and attach to it, it currently will spawn the process, but it won't attach to it just yet. This will let LLDB not have to share the terminal with another process and a new terminal window will pop up when you launch. This won't get hooked up until we work out all of the kinks. The new Host function is: static lldb::pid_t Host::LaunchInNewTerminal ( const char **argv, // argv[0] is executable const char **envp, const ArchSpec *arch_spec, bool stop_at_entry, bool disable_aslr); Cleaned up FileSpec::GetPath to not use strncpy() as it was always zero filling the entire path buffer. Fixed an issue with the dynamic checker function where I missed a '$' prefix that should have been added. llvm-svn: 116690
2010-10-18 06:03:32 +08:00
#include "cfcpp/CFCMutableArray.h"
Cleaned up a unused member variable in Debugger. Added the start of Host specific launch services, though it currently isn't hookup up to anything. We want to be able to launch a process and use the native launch services to launch an app like it would be launched by the user double clicking on the app. We also eventually want to be able to run a command line app in a newly spawned terminal to avoid terminal sharing. Fixed an issue with the new DWARF forward type declaration stuff. A crasher was found that was happening when trying to properly expand the forward declarations. llvm-svn: 115213
2010-10-01 05:49:03 +08:00
#include "cfcpp/CFCMutableDictionary.h"
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. llvm-svn: 108009
2010-07-10 04:39:50 +08:00
#include "cfcpp/CFCReleaser.h"
#include "cfcpp/CFCString.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Patch from Jay Cornwall that modifies the LLDB "Host" layer to reuse more code between linux, darwin and BSD. llvm-svn: 113263
2010-09-08 04:11:56 +08:00
#include <objc/objc-auto.h>
Unify how we get host version on Mac OS X & iOS. Also remove our dependency on UIKit & AppKit. Cleaned up the project files a bit. <rdar://problem/11814498> llvm-svn: 160147
2012-07-13 07:16:43 +08:00
#include <CoreFoundation/CoreFoundation.h>
#include <Foundation/Foundation.h>
#if !defined(__arm__)
Patch from Jay Cornwall that modifies the LLDB "Host" layer to reuse more code between linux, darwin and BSD. llvm-svn: 113263
2010-09-08 04:11:56 +08:00
#include <Carbon/Carbon.h>
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
#endif
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
#ifndef _POSIX_SPAWN_DISABLE_ASLR
#define _POSIX_SPAWN_DISABLE_ASLR 0x0100
#endif
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. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
extern "C"
{
int __pthread_chdir(const char *path);
int __pthread_fchdir (int fildes);
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
using namespace lldb;
using namespace lldb_private;
Fixed an issue with the pthread_setspecific() where we weren't NULL-ing out the thread specific data and were destroying the thread specfic data more than once. Also added the ability to ask a lldb::StateType if it is stopped with an additional paramter of "must_exist" which means that the state must be a stopped state for a process that still exists. This means that eStateExited and eStateUnloaded will no longer return true if "must_exist" is set to true. llvm-svn: 144875
2011-11-17 09:23:07 +08:00
static pthread_once_t g_thread_create_once = PTHREAD_ONCE_INIT;
static pthread_key_t g_thread_create_key = 0;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
class MacOSXDarwinThread
{
public:
MacOSXDarwinThread(const char *thread_name) :
m_pool (nil)
{
// Register our thread with the collector if garbage collection is enabled.
if (objc_collectingEnabled())
{
#if MAC_OS_X_VERSION_MAX_ALLOWED <= MAC_OS_X_VERSION_10_5
// On Leopard and earlier there is no way objc_registerThreadWithCollector
// function, so we do it manually.
auto_zone_register_thread(auto_zone());
#else
Spelling changes applied from lldb_spelling.diffs from Bruce Mitchener. Thanks Bruce! llvm-svn: 123083
2011-01-09 04:28:42 +08:00
// On SnowLeopard and later we just call the thread registration function.
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
objc_registerThreadWithCollector();
#endif
}
else
{
m_pool = [[NSAutoreleasePool alloc] init];
}
Host::SetThreadName (LLDB_INVALID_PROCESS_ID, LLDB_INVALID_THREAD_ID, thread_name);
}
~MacOSXDarwinThread()
{
if (m_pool)
Fixed an issue with the pthread_setspecific() where we weren't NULL-ing out the thread specific data and were destroying the thread specfic data more than once. Also added the ability to ask a lldb::StateType if it is stopped with an additional paramter of "must_exist" which means that the state must be a stopped state for a process that still exists. This means that eStateExited and eStateUnloaded will no longer return true if "must_exist" is set to true. llvm-svn: 144875
2011-11-17 09:23:07 +08:00
{
Call "drain" on the auto release pool as it will do the right thing for both GC and non-GC apps. It will also quiet the static analyzer. llvm-svn: 160390
2012-07-18 03:46:12 +08:00
[m_pool drain];
Fixed an issue with the pthread_setspecific() where we weren't NULL-ing out the thread specific data and were destroying the thread specfic data more than once. Also added the ability to ask a lldb::StateType if it is stopped with an additional paramter of "must_exist" which means that the state must be a stopped state for a process that still exists. This means that eStateExited and eStateUnloaded will no longer return true if "must_exist" is set to true. llvm-svn: 144875
2011-11-17 09:23:07 +08:00
m_pool = nil;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
static void PThreadDestructor (void *v)
{
Fixed an issue with the pthread_setspecific() where we weren't NULL-ing out the thread specific data and were destroying the thread specfic data more than once. Also added the ability to ask a lldb::StateType if it is stopped with an additional paramter of "must_exist" which means that the state must be a stopped state for a process that still exists. This means that eStateExited and eStateUnloaded will no longer return true if "must_exist" is set to true. llvm-svn: 144875
2011-11-17 09:23:07 +08:00
if (v)
delete static_cast<MacOSXDarwinThread*>(v);
::pthread_setspecific (g_thread_create_key, NULL);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
protected:
NSAutoreleasePool * m_pool;
private:
DISALLOW_COPY_AND_ASSIGN (MacOSXDarwinThread);
};
static void
InitThreadCreated()
{
::pthread_key_create (&g_thread_create_key, MacOSXDarwinThread::PThreadDestructor);
}
void
Host::ThreadCreated (const char *thread_name)
{
::pthread_once (&g_thread_create_once, InitThreadCreated);
if (g_thread_create_key)
{
::pthread_setspecific (g_thread_create_key, new MacOSXDarwinThread(thread_name));
}
}
Add support for listing inferior thread names on Linux. llvm-svn: 186033
2013-07-11 04:53:11 +08:00
std::string
Host::GetThreadName (lldb::pid_t pid, lldb::tid_t tid)
{
std::string thread_name;
#if MAC_OS_X_VERSION_MAX_ALLOWED > MAC_OS_X_VERSION_10_5
// We currently can only get the name of a thread in the current process.
if (pid == Host::GetCurrentProcessID())
{
char pthread_name[1024];
if (::pthread_getname_np (::pthread_from_mach_thread_np (tid), pthread_name, sizeof(pthread_name)) == 0)
{
if (pthread_name[0])
{
thread_name = pthread_name;
}
}
else
{
dispatch_queue_t current_queue = ::dispatch_get_current_queue ();
if (current_queue != NULL)
{
const char *queue_name = dispatch_queue_get_label (current_queue);
if (queue_name && queue_name[0])
{
thread_name = queue_name;
}
}
}
}
#endif
return thread_name;
}
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. llvm-svn: 150426
2012-02-14 07:10:39 +08:00
bool
Host::GetBundleDirectory (const FileSpec &file, FileSpec &bundle_directory)
{
#if defined (__APPLE__)
if (file.GetFileType () == FileSpec::eFileTypeDirectory)
{
char path[PATH_MAX];
if (file.GetPath(path, sizeof(path)))
{
CFCBundle bundle (path);
if (bundle.GetPath (path, sizeof(path)))
{
bundle_directory.SetFile (path, false);
return true;
}
}
}
#endif
bundle_directory.Clear();
return false;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
bool
Added a new Host call to find LLDB related paths: static bool Host::GetLLDBPath (lldb::PathType path_type, FileSpec &file_spec); This will fill in "file_spec" with an appropriate path that is appropriate for the current Host OS. MacOSX will return paths within the LLDB.framework, and other unixes will return the paths they want. The current PathType enums are: typedef enum PathType { ePathTypeLLDBShlibDir, // The directory where the lldb.so (unix) or LLDB mach-o file in LLDB.framework (MacOSX) exists ePathTypeSupportExecutableDir, // Find LLDB support executable directory (debugserver, etc) ePathTypeHeaderDir, // Find LLDB header file directory ePathTypePythonDir // Find Python modules (PYTHONPATH) directory } PathType; All places that were finding executables are and python paths are now updated to use this Host call. Added another new host call to launch the inferior in a terminal. This ability will be very host specific and doesn't need to be supported on all systems. MacOSX currently will create a new .command file and tell Terminal.app to open the .command file. It also uses the new "darwin-debug" app which is a small app that uses posix to exec (no fork) and stop at the entry point of the program. The GDB remote plug-in is almost able launch a process and attach to it, it currently will spawn the process, but it won't attach to it just yet. This will let LLDB not have to share the terminal with another process and a new terminal window will pop up when you launch. This won't get hooked up until we work out all of the kinks. The new Host function is: static lldb::pid_t Host::LaunchInNewTerminal ( const char **argv, // argv[0] is executable const char **envp, const ArchSpec *arch_spec, bool stop_at_entry, bool disable_aslr); Cleaned up FileSpec::GetPath to not use strncpy() as it was always zero filling the entire path buffer. Fixed an issue with the dynamic checker function where I missed a '$' prefix that should have been added. llvm-svn: 116690
2010-10-18 06:03:32 +08:00
Host::ResolveExecutableInBundle (FileSpec &file)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Patch from Jay Cornwall that modifies the LLDB "Host" layer to reuse more code between linux, darwin and BSD. llvm-svn: 113263
2010-09-08 04:11:56 +08:00
#if defined (__APPLE__)
Added a new Host call to find LLDB related paths: static bool Host::GetLLDBPath (lldb::PathType path_type, FileSpec &file_spec); This will fill in "file_spec" with an appropriate path that is appropriate for the current Host OS. MacOSX will return paths within the LLDB.framework, and other unixes will return the paths they want. The current PathType enums are: typedef enum PathType { ePathTypeLLDBShlibDir, // The directory where the lldb.so (unix) or LLDB mach-o file in LLDB.framework (MacOSX) exists ePathTypeSupportExecutableDir, // Find LLDB support executable directory (debugserver, etc) ePathTypeHeaderDir, // Find LLDB header file directory ePathTypePythonDir // Find Python modules (PYTHONPATH) directory } PathType; All places that were finding executables are and python paths are now updated to use this Host call. Added another new host call to launch the inferior in a terminal. This ability will be very host specific and doesn't need to be supported on all systems. MacOSX currently will create a new .command file and tell Terminal.app to open the .command file. It also uses the new "darwin-debug" app which is a small app that uses posix to exec (no fork) and stop at the entry point of the program. The GDB remote plug-in is almost able launch a process and attach to it, it currently will spawn the process, but it won't attach to it just yet. This will let LLDB not have to share the terminal with another process and a new terminal window will pop up when you launch. This won't get hooked up until we work out all of the kinks. The new Host function is: static lldb::pid_t Host::LaunchInNewTerminal ( const char **argv, // argv[0] is executable const char **envp, const ArchSpec *arch_spec, bool stop_at_entry, bool disable_aslr); Cleaned up FileSpec::GetPath to not use strncpy() as it was always zero filling the entire path buffer. Fixed an issue with the dynamic checker function where I missed a '$' prefix that should have been added. llvm-svn: 116690
2010-10-18 06:03:32 +08:00
if (file.GetFileType () == FileSpec::eFileTypeDirectory)
Patch from Jay Cornwall that modifies the LLDB "Host" layer to reuse more code between linux, darwin and BSD. llvm-svn: 113263
2010-09-08 04:11:56 +08:00
{
Added a new Host call to find LLDB related paths: static bool Host::GetLLDBPath (lldb::PathType path_type, FileSpec &file_spec); This will fill in "file_spec" with an appropriate path that is appropriate for the current Host OS. MacOSX will return paths within the LLDB.framework, and other unixes will return the paths they want. The current PathType enums are: typedef enum PathType { ePathTypeLLDBShlibDir, // The directory where the lldb.so (unix) or LLDB mach-o file in LLDB.framework (MacOSX) exists ePathTypeSupportExecutableDir, // Find LLDB support executable directory (debugserver, etc) ePathTypeHeaderDir, // Find LLDB header file directory ePathTypePythonDir // Find Python modules (PYTHONPATH) directory } PathType; All places that were finding executables are and python paths are now updated to use this Host call. Added another new host call to launch the inferior in a terminal. This ability will be very host specific and doesn't need to be supported on all systems. MacOSX currently will create a new .command file and tell Terminal.app to open the .command file. It also uses the new "darwin-debug" app which is a small app that uses posix to exec (no fork) and stop at the entry point of the program. The GDB remote plug-in is almost able launch a process and attach to it, it currently will spawn the process, but it won't attach to it just yet. This will let LLDB not have to share the terminal with another process and a new terminal window will pop up when you launch. This won't get hooked up until we work out all of the kinks. The new Host function is: static lldb::pid_t Host::LaunchInNewTerminal ( const char **argv, // argv[0] is executable const char **envp, const ArchSpec *arch_spec, bool stop_at_entry, bool disable_aslr); Cleaned up FileSpec::GetPath to not use strncpy() as it was always zero filling the entire path buffer. Fixed an issue with the dynamic checker function where I missed a '$' prefix that should have been added. llvm-svn: 116690
2010-10-18 06:03:32 +08:00
char path[PATH_MAX];
if (file.GetPath(path, sizeof(path)))
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
{
Added a new Host call to find LLDB related paths: static bool Host::GetLLDBPath (lldb::PathType path_type, FileSpec &file_spec); This will fill in "file_spec" with an appropriate path that is appropriate for the current Host OS. MacOSX will return paths within the LLDB.framework, and other unixes will return the paths they want. The current PathType enums are: typedef enum PathType { ePathTypeLLDBShlibDir, // The directory where the lldb.so (unix) or LLDB mach-o file in LLDB.framework (MacOSX) exists ePathTypeSupportExecutableDir, // Find LLDB support executable directory (debugserver, etc) ePathTypeHeaderDir, // Find LLDB header file directory ePathTypePythonDir // Find Python modules (PYTHONPATH) directory } PathType; All places that were finding executables are and python paths are now updated to use this Host call. Added another new host call to launch the inferior in a terminal. This ability will be very host specific and doesn't need to be supported on all systems. MacOSX currently will create a new .command file and tell Terminal.app to open the .command file. It also uses the new "darwin-debug" app which is a small app that uses posix to exec (no fork) and stop at the entry point of the program. The GDB remote plug-in is almost able launch a process and attach to it, it currently will spawn the process, but it won't attach to it just yet. This will let LLDB not have to share the terminal with another process and a new terminal window will pop up when you launch. This won't get hooked up until we work out all of the kinks. The new Host function is: static lldb::pid_t Host::LaunchInNewTerminal ( const char **argv, // argv[0] is executable const char **envp, const ArchSpec *arch_spec, bool stop_at_entry, bool disable_aslr); Cleaned up FileSpec::GetPath to not use strncpy() as it was always zero filling the entire path buffer. Fixed an issue with the dynamic checker function where I missed a '$' prefix that should have been added. llvm-svn: 116690
2010-10-18 06:03:32 +08:00
CFCBundle bundle (path);
CFCReleaser<CFURLRef> url(bundle.CopyExecutableURL ());
if (url.get())
{
if (::CFURLGetFileSystemRepresentation (url.get(), YES, (UInt8*)path, sizeof(path)))
{
Fixed an issue where we were resolving paths when we should have been. So the issue here was that we have lldb_private::FileSpec that by default was always resolving a path when using the: FileSpec::FileSpec (const char *path); and in the: void FileSpec::SetFile(const char *pathname, bool resolve = true); This isn't what we want in many many cases. One example is you have "/tmp" on your file system which is really "/private/tmp". You compile code in that directory and end up with debug info that mentions "/tmp/file.c". Then you type: (lldb) breakpoint set --file file.c --line 5 If your current working directory is "/tmp", then "file.c" would be turned into "/private/tmp/file.c" which won't match anything in the debug info. Also, it should have been just a FileSpec with no directory and a filename of "file.c" which could (and should) potentially match any instances of "file.c" in the debug info. So I removed the constructor that just takes a path: FileSpec::FileSpec (const char *path); // REMOVED You must now use the other constructor that has a "bool resolve" parameter that you must always supply: FileSpec::FileSpec (const char *path, bool resolve); I also removed the default parameter to SetFile(): void FileSpec::SetFile(const char *pathname, bool resolve); And fixed all of the code to use the right settings. llvm-svn: 116944
2010-10-21 04:54:39 +08:00
file.SetFile(path, false);
Added a new Host call to find LLDB related paths: static bool Host::GetLLDBPath (lldb::PathType path_type, FileSpec &file_spec); This will fill in "file_spec" with an appropriate path that is appropriate for the current Host OS. MacOSX will return paths within the LLDB.framework, and other unixes will return the paths they want. The current PathType enums are: typedef enum PathType { ePathTypeLLDBShlibDir, // The directory where the lldb.so (unix) or LLDB mach-o file in LLDB.framework (MacOSX) exists ePathTypeSupportExecutableDir, // Find LLDB support executable directory (debugserver, etc) ePathTypeHeaderDir, // Find LLDB header file directory ePathTypePythonDir // Find Python modules (PYTHONPATH) directory } PathType; All places that were finding executables are and python paths are now updated to use this Host call. Added another new host call to launch the inferior in a terminal. This ability will be very host specific and doesn't need to be supported on all systems. MacOSX currently will create a new .command file and tell Terminal.app to open the .command file. It also uses the new "darwin-debug" app which is a small app that uses posix to exec (no fork) and stop at the entry point of the program. The GDB remote plug-in is almost able launch a process and attach to it, it currently will spawn the process, but it won't attach to it just yet. This will let LLDB not have to share the terminal with another process and a new terminal window will pop up when you launch. This won't get hooked up until we work out all of the kinks. The new Host function is: static lldb::pid_t Host::LaunchInNewTerminal ( const char **argv, // argv[0] is executable const char **envp, const ArchSpec *arch_spec, bool stop_at_entry, bool disable_aslr); Cleaned up FileSpec::GetPath to not use strncpy() as it was always zero filling the entire path buffer. Fixed an issue with the dynamic checker function where I missed a '$' prefix that should have been added. llvm-svn: 116690
2010-10-18 06:03:32 +08:00
return true;
}
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
}
Patch from Jay Cornwall that modifies the LLDB "Host" layer to reuse more code between linux, darwin and BSD. llvm-svn: 113263
2010-09-08 04:11:56 +08:00
#endif
return false;
Change Target & Process so they can really be initialized with an invalid architecture. Arrange that this then gets properly set on attach, or when a "file" is set. Add a completer for "process attach -n". Caveats: there isn't currently a way to handle multiple processes with the same name. That will have to wait on a way to pass annotations along with the completion strings. llvm-svn: 110624
2010-08-10 07:31:02 +08:00
}
Added a way to open the current source file & line in an external editor, and you can turn this on with: lldb -e llvm-svn: 112502
2010-08-31 03:44:40 +08:00
Cleaned up a unused member variable in Debugger. Added the start of Host specific launch services, though it currently isn't hookup up to anything. We want to be able to launch a process and use the native launch services to launch an app like it would be launched by the user double clicking on the app. We also eventually want to be able to run a command line app in a newly spawned terminal to avoid terminal sharing. Fixed an issue with the new DWARF forward type declaration stuff. A crasher was found that was happening when trying to properly expand the forward declarations. llvm-svn: 115213
2010-10-01 05:49:03 +08:00
lldb::pid_t
Host::LaunchApplication (const FileSpec &app_file_spec)
{
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
#if defined (__arm__)
return LLDB_INVALID_PROCESS_ID;
#else
Cleaned up a unused member variable in Debugger. Added the start of Host specific launch services, though it currently isn't hookup up to anything. We want to be able to launch a process and use the native launch services to launch an app like it would be launched by the user double clicking on the app. We also eventually want to be able to run a command line app in a newly spawned terminal to avoid terminal sharing. Fixed an issue with the new DWARF forward type declaration stuff. A crasher was found that was happening when trying to properly expand the forward declarations. llvm-svn: 115213
2010-10-01 05:49:03 +08:00
char app_path[PATH_MAX];
app_file_spec.GetPath(app_path, sizeof(app_path));
LSApplicationParameters app_params;
Remove bzero use and replace with memset (patch from Kirk Beitz). llvm-svn: 124897
2011-02-05 05:13:05 +08:00
::memset (&app_params, 0, sizeof (app_params));
Cleaned up a unused member variable in Debugger. Added the start of Host specific launch services, though it currently isn't hookup up to anything. We want to be able to launch a process and use the native launch services to launch an app like it would be launched by the user double clicking on the app. We also eventually want to be able to run a command line app in a newly spawned terminal to avoid terminal sharing. Fixed an issue with the new DWARF forward type declaration stuff. A crasher was found that was happening when trying to properly expand the forward declarations. llvm-svn: 115213
2010-10-01 05:49:03 +08:00
app_params.flags = kLSLaunchDefaults |
kLSLaunchDontAddToRecents |
Added a new Host call to find LLDB related paths: static bool Host::GetLLDBPath (lldb::PathType path_type, FileSpec &file_spec); This will fill in "file_spec" with an appropriate path that is appropriate for the current Host OS. MacOSX will return paths within the LLDB.framework, and other unixes will return the paths they want. The current PathType enums are: typedef enum PathType { ePathTypeLLDBShlibDir, // The directory where the lldb.so (unix) or LLDB mach-o file in LLDB.framework (MacOSX) exists ePathTypeSupportExecutableDir, // Find LLDB support executable directory (debugserver, etc) ePathTypeHeaderDir, // Find LLDB header file directory ePathTypePythonDir // Find Python modules (PYTHONPATH) directory } PathType; All places that were finding executables are and python paths are now updated to use this Host call. Added another new host call to launch the inferior in a terminal. This ability will be very host specific and doesn't need to be supported on all systems. MacOSX currently will create a new .command file and tell Terminal.app to open the .command file. It also uses the new "darwin-debug" app which is a small app that uses posix to exec (no fork) and stop at the entry point of the program. The GDB remote plug-in is almost able launch a process and attach to it, it currently will spawn the process, but it won't attach to it just yet. This will let LLDB not have to share the terminal with another process and a new terminal window will pop up when you launch. This won't get hooked up until we work out all of the kinks. The new Host function is: static lldb::pid_t Host::LaunchInNewTerminal ( const char **argv, // argv[0] is executable const char **envp, const ArchSpec *arch_spec, bool stop_at_entry, bool disable_aslr); Cleaned up FileSpec::GetPath to not use strncpy() as it was always zero filling the entire path buffer. Fixed an issue with the dynamic checker function where I missed a '$' prefix that should have been added. llvm-svn: 116690
2010-10-18 06:03:32 +08:00
kLSLaunchNewInstance;
Cleaned up a unused member variable in Debugger. Added the start of Host specific launch services, though it currently isn't hookup up to anything. We want to be able to launch a process and use the native launch services to launch an app like it would be launched by the user double clicking on the app. We also eventually want to be able to run a command line app in a newly spawned terminal to avoid terminal sharing. Fixed an issue with the new DWARF forward type declaration stuff. A crasher was found that was happening when trying to properly expand the forward declarations. llvm-svn: 115213
2010-10-01 05:49:03 +08:00
FSRef app_fsref;
CFCString app_cfstr (app_path, kCFStringEncodingUTF8);
Silence a bunch of clang warnings. llvm-svn: 118710
2010-11-11 04:16:47 +08:00
OSStatus error = ::FSPathMakeRef ((const UInt8 *)app_path, &app_fsref, NULL);
Cleaned up a unused member variable in Debugger. Added the start of Host specific launch services, though it currently isn't hookup up to anything. We want to be able to launch a process and use the native launch services to launch an app like it would be launched by the user double clicking on the app. We also eventually want to be able to run a command line app in a newly spawned terminal to avoid terminal sharing. Fixed an issue with the new DWARF forward type declaration stuff. A crasher was found that was happening when trying to properly expand the forward declarations. llvm-svn: 115213
2010-10-01 05:49:03 +08:00
// If we found the app, then store away the name so we don't have to re-look it up.
if (error != noErr)
return LLDB_INVALID_PROCESS_ID;
app_params.application = &app_fsref;
ProcessSerialNumber psn;
error = ::LSOpenApplication (&app_params, &psn);
if (error != noErr)
return LLDB_INVALID_PROCESS_ID;
Added a new Host call to find LLDB related paths: static bool Host::GetLLDBPath (lldb::PathType path_type, FileSpec &file_spec); This will fill in "file_spec" with an appropriate path that is appropriate for the current Host OS. MacOSX will return paths within the LLDB.framework, and other unixes will return the paths they want. The current PathType enums are: typedef enum PathType { ePathTypeLLDBShlibDir, // The directory where the lldb.so (unix) or LLDB mach-o file in LLDB.framework (MacOSX) exists ePathTypeSupportExecutableDir, // Find LLDB support executable directory (debugserver, etc) ePathTypeHeaderDir, // Find LLDB header file directory ePathTypePythonDir // Find Python modules (PYTHONPATH) directory } PathType; All places that were finding executables are and python paths are now updated to use this Host call. Added another new host call to launch the inferior in a terminal. This ability will be very host specific and doesn't need to be supported on all systems. MacOSX currently will create a new .command file and tell Terminal.app to open the .command file. It also uses the new "darwin-debug" app which is a small app that uses posix to exec (no fork) and stop at the entry point of the program. The GDB remote plug-in is almost able launch a process and attach to it, it currently will spawn the process, but it won't attach to it just yet. This will let LLDB not have to share the terminal with another process and a new terminal window will pop up when you launch. This won't get hooked up until we work out all of the kinks. The new Host function is: static lldb::pid_t Host::LaunchInNewTerminal ( const char **argv, // argv[0] is executable const char **envp, const ArchSpec *arch_spec, bool stop_at_entry, bool disable_aslr); Cleaned up FileSpec::GetPath to not use strncpy() as it was always zero filling the entire path buffer. Fixed an issue with the dynamic checker function where I missed a '$' prefix that should have been added. llvm-svn: 116690
2010-10-18 06:03:32 +08:00
::pid_t pid = LLDB_INVALID_PROCESS_ID;
error = ::GetProcessPID(&psn, &pid);
Ran the static analyzer on the codebase and found a few things. llvm-svn: 160338
2012-07-17 11:23:13 +08:00
if (error != noErr)
return LLDB_INVALID_PROCESS_ID;
Added a new Host call to find LLDB related paths: static bool Host::GetLLDBPath (lldb::PathType path_type, FileSpec &file_spec); This will fill in "file_spec" with an appropriate path that is appropriate for the current Host OS. MacOSX will return paths within the LLDB.framework, and other unixes will return the paths they want. The current PathType enums are: typedef enum PathType { ePathTypeLLDBShlibDir, // The directory where the lldb.so (unix) or LLDB mach-o file in LLDB.framework (MacOSX) exists ePathTypeSupportExecutableDir, // Find LLDB support executable directory (debugserver, etc) ePathTypeHeaderDir, // Find LLDB header file directory ePathTypePythonDir // Find Python modules (PYTHONPATH) directory } PathType; All places that were finding executables are and python paths are now updated to use this Host call. Added another new host call to launch the inferior in a terminal. This ability will be very host specific and doesn't need to be supported on all systems. MacOSX currently will create a new .command file and tell Terminal.app to open the .command file. It also uses the new "darwin-debug" app which is a small app that uses posix to exec (no fork) and stop at the entry point of the program. The GDB remote plug-in is almost able launch a process and attach to it, it currently will spawn the process, but it won't attach to it just yet. This will let LLDB not have to share the terminal with another process and a new terminal window will pop up when you launch. This won't get hooked up until we work out all of the kinks. The new Host function is: static lldb::pid_t Host::LaunchInNewTerminal ( const char **argv, // argv[0] is executable const char **envp, const ArchSpec *arch_spec, bool stop_at_entry, bool disable_aslr); Cleaned up FileSpec::GetPath to not use strncpy() as it was always zero filling the entire path buffer. Fixed an issue with the dynamic checker function where I missed a '$' prefix that should have been added. llvm-svn: 116690
2010-10-18 06:03:32 +08:00
return pid;
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
#endif
Added a new Host call to find LLDB related paths: static bool Host::GetLLDBPath (lldb::PathType path_type, FileSpec &file_spec); This will fill in "file_spec" with an appropriate path that is appropriate for the current Host OS. MacOSX will return paths within the LLDB.framework, and other unixes will return the paths they want. The current PathType enums are: typedef enum PathType { ePathTypeLLDBShlibDir, // The directory where the lldb.so (unix) or LLDB mach-o file in LLDB.framework (MacOSX) exists ePathTypeSupportExecutableDir, // Find LLDB support executable directory (debugserver, etc) ePathTypeHeaderDir, // Find LLDB header file directory ePathTypePythonDir // Find Python modules (PYTHONPATH) directory } PathType; All places that were finding executables are and python paths are now updated to use this Host call. Added another new host call to launch the inferior in a terminal. This ability will be very host specific and doesn't need to be supported on all systems. MacOSX currently will create a new .command file and tell Terminal.app to open the .command file. It also uses the new "darwin-debug" app which is a small app that uses posix to exec (no fork) and stop at the entry point of the program. The GDB remote plug-in is almost able launch a process and attach to it, it currently will spawn the process, but it won't attach to it just yet. This will let LLDB not have to share the terminal with another process and a new terminal window will pop up when you launch. This won't get hooked up until we work out all of the kinks. The new Host function is: static lldb::pid_t Host::LaunchInNewTerminal ( const char **argv, // argv[0] is executable const char **envp, const ArchSpec *arch_spec, bool stop_at_entry, bool disable_aslr); Cleaned up FileSpec::GetPath to not use strncpy() as it was always zero filling the entire path buffer. Fixed an issue with the dynamic checker function where I missed a '$' prefix that should have been added. llvm-svn: 116690
2010-10-18 06:03:32 +08:00
}
Use AppleScript when lauching inferior in terminal so the command that is being run is visible in the terminal as opposed to just seeing a path to a .command file. llvm-svn: 116814
2010-10-20 01:03:58 +08:00
Fixed all known race conditions with starting a process in a new terminal. We now spawn a thread to accept a unix socket connection from the inferior when it spawns in the terminal, then we launch the process, then we get the pid back through the unix socket, and then wait for it to SIGSTOP. darwin-debug now clears the terminal screen and prints out the program and arguments that are about to be launched. llvm-svn: 116841
2010-10-20 02:15:50 +08:00
static void *
AcceptPIDFromInferior (void *arg)
{
const char *connect_url = (const char *)arg;
Use AppleScript when lauching inferior in terminal so the command that is being run is visible in the terminal as opposed to just seeing a path to a .command file. llvm-svn: 116814
2010-10-20 01:03:58 +08:00
ConnectionFileDescriptor file_conn;
Fixed all known race conditions with starting a process in a new terminal. We now spawn a thread to accept a unix socket connection from the inferior when it spawns in the terminal, then we launch the process, then we get the pid back through the unix socket, and then wait for it to SIGSTOP. darwin-debug now clears the terminal screen and prints out the program and arguments that are about to be launched. llvm-svn: 116841
2010-10-20 02:15:50 +08:00
Error error;
if (file_conn.Connect (connect_url, &error) == eConnectionStatusSuccess)
Use AppleScript when lauching inferior in terminal so the command that is being run is visible in the terminal as opposed to just seeing a path to a .command file. llvm-svn: 116814
2010-10-20 01:03:58 +08:00
{
char pid_str[256];
Remove bzero use and replace with memset (patch from Kirk Beitz). llvm-svn: 124897
2011-02-05 05:13:05 +08:00
::memset (pid_str, 0, sizeof(pid_str));
Use AppleScript when lauching inferior in terminal so the command that is being run is visible in the terminal as opposed to just seeing a path to a .command file. llvm-svn: 116814
2010-10-20 01:03:58 +08:00
ConnectionStatus status;
Use the path to the header file. Use an integer instead of NULL. And get rid of a superfluous 'default' label. llvm-svn: 153943
2012-04-03 15:51:16 +08:00
const size_t pid_str_len = file_conn.Read (pid_str, sizeof(pid_str), 0, status, NULL);
Use AppleScript when lauching inferior in terminal so the command that is being run is visible in the terminal as opposed to just seeing a path to a .command file. llvm-svn: 116814
2010-10-20 01:03:58 +08:00
if (pid_str_len > 0)
{
Fixed all known race conditions with starting a process in a new terminal. We now spawn a thread to accept a unix socket connection from the inferior when it spawns in the terminal, then we launch the process, then we get the pid back through the unix socket, and then wait for it to SIGSTOP. darwin-debug now clears the terminal screen and prints out the program and arguments that are about to be launched. llvm-svn: 116841
2010-10-20 02:15:50 +08:00
int pid = atoi (pid_str);
return (void *)(intptr_t)pid;
Use AppleScript when lauching inferior in terminal so the command that is being run is visible in the terminal as opposed to just seeing a path to a .command file. llvm-svn: 116814
2010-10-20 01:03:58 +08:00
}
}
Fixed all known race conditions with starting a process in a new terminal. We now spawn a thread to accept a unix socket connection from the inferior when it spawns in the terminal, then we launch the process, then we get the pid back through the unix socket, and then wait for it to SIGSTOP. darwin-debug now clears the terminal screen and prints out the program and arguments that are about to be launched. llvm-svn: 116841
2010-10-20 02:15:50 +08:00
return NULL;
Use AppleScript when lauching inferior in terminal so the command that is being run is visible in the terminal as opposed to just seeing a path to a .command file. llvm-svn: 116814
2010-10-20 01:03:58 +08:00
}
Fixed all known race conditions with starting a process in a new terminal. We now spawn a thread to accept a unix socket connection from the inferior when it spawns in the terminal, then we launch the process, then we get the pid back through the unix socket, and then wait for it to SIGSTOP. darwin-debug now clears the terminal screen and prints out the program and arguments that are about to be launched. llvm-svn: 116841
2010-10-20 02:15:50 +08:00
static bool
WaitForProcessToSIGSTOP (const lldb::pid_t pid, const int timeout_in_seconds)
{
const int time_delta_usecs = 100000;
const int num_retries = timeout_in_seconds/time_delta_usecs;
for (int i=0; i<num_retries; i++)
{
struct proc_bsdinfo bsd_info;
int error = ::proc_pidinfo (pid, PROC_PIDTBSDINFO,
(uint64_t) 0,
&bsd_info,
PROC_PIDTBSDINFO_SIZE);
switch (error)
{
case EINVAL:
case ENOTSUP:
case ESRCH:
case EPERM:
return false;
default:
break;
case 0:
if (bsd_info.pbi_status == SSTOP)
return true;
}
::usleep (time_delta_usecs);
}
return false;
}
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
#if !defined(__arm__)
Fixed all known race conditions with starting a process in a new terminal. We now spawn a thread to accept a unix socket connection from the inferior when it spawns in the terminal, then we launch the process, then we get the pid back through the unix socket, and then wait for it to SIGSTOP. darwin-debug now clears the terminal screen and prints out the program and arguments that are about to be launched. llvm-svn: 116841
2010-10-20 02:15:50 +08:00
Ran the static analyzer on the codebase and found a few things. llvm-svn: 160338
2012-07-17 11:23:13 +08:00
//static lldb::pid_t
//LaunchInNewTerminalWithCommandFile
//(
// const char **argv,
// const char **envp,
// const char *working_dir,
// const ArchSpec *arch_spec,
// bool stop_at_entry,
// bool disable_aslr
//)
//{
// if (!argv || !argv[0])
// return LLDB_INVALID_PROCESS_ID;
//
// OSStatus error = 0;
//
// FileSpec program (argv[0], false);
//
//
// std::string unix_socket_name;
//
// char temp_file_path[PATH_MAX];
// const char *tmpdir = ::getenv ("TMPDIR");
// if (tmpdir == NULL)
// tmpdir = "/tmp/";
// ::snprintf (temp_file_path, sizeof(temp_file_path), "%s%s-XXXXXX", tmpdir, program.GetFilename().AsCString());
//
// if (::mktemp (temp_file_path) == NULL)
// return LLDB_INVALID_PROCESS_ID;
//
// unix_socket_name.assign (temp_file_path);
//
// ::strlcat (temp_file_path, ".command", sizeof (temp_file_path));
//
// StreamFile command_file;
// command_file.GetFile().Open (temp_file_path,
// File::eOpenOptionWrite | File::eOpenOptionCanCreate,
// File::ePermissionsDefault);
//
// if (!command_file.GetFile().IsValid())
// return LLDB_INVALID_PROCESS_ID;
//
// FileSpec darwin_debug_file_spec;
// if (!Host::GetLLDBPath (ePathTypeSupportExecutableDir, darwin_debug_file_spec))
// return LLDB_INVALID_PROCESS_ID;
// darwin_debug_file_spec.GetFilename().SetCString("darwin-debug");
//
// if (!darwin_debug_file_spec.Exists())
// return LLDB_INVALID_PROCESS_ID;
//
// char launcher_path[PATH_MAX];
// darwin_debug_file_spec.GetPath(launcher_path, sizeof(launcher_path));
// command_file.Printf("\"%s\" ", launcher_path);
//
// command_file.Printf("--unix-socket=%s ", unix_socket_name.c_str());
//
// if (arch_spec && arch_spec->IsValid())
// {
// command_file.Printf("--arch=%s ", arch_spec->GetArchitectureName());
// }
//
// if (disable_aslr)
// {
// command_file.PutCString("--disable-aslr ");
// }
//
// command_file.PutCString("-- ");
//
// if (argv)
// {
// for (size_t i=0; argv[i] != NULL; ++i)
// {
// command_file.Printf("\"%s\" ", argv[i]);
// }
// }
// command_file.PutCString("\necho Process exited with status $?\n");
// command_file.GetFile().Close();
// if (::chmod (temp_file_path, S_IRWXU | S_IRWXG) != 0)
// return LLDB_INVALID_PROCESS_ID;
//
// CFCMutableDictionary cf_env_dict;
//
// const bool can_create = true;
// if (envp)
// {
// for (size_t i=0; envp[i] != NULL; ++i)
// {
// const char *env_entry = envp[i];
// const char *equal_pos = strchr(env_entry, '=');
// if (equal_pos)
// {
// std::string env_key (env_entry, equal_pos);
// std::string env_val (equal_pos + 1);
// CFCString cf_env_key (env_key.c_str(), kCFStringEncodingUTF8);
// CFCString cf_env_val (env_val.c_str(), kCFStringEncodingUTF8);
// cf_env_dict.AddValue (cf_env_key.get(), cf_env_val.get(), can_create);
// }
// }
// }
//
// LSApplicationParameters app_params;
// ::memset (&app_params, 0, sizeof (app_params));
// app_params.flags = kLSLaunchDontAddToRecents | kLSLaunchAsync;
// app_params.argv = NULL;
// app_params.environment = (CFDictionaryRef)cf_env_dict.get();
//
// CFCReleaser<CFURLRef> command_file_url (::CFURLCreateFromFileSystemRepresentation (NULL,
// (const UInt8 *)temp_file_path,
// strlen(temp_file_path),
// false));
//
// CFCMutableArray urls;
//
// // Terminal.app will open the ".command" file we have created
// // and run our process inside it which will wait at the entry point
// // for us to attach.
// urls.AppendValue(command_file_url.get());
//
//
// lldb::pid_t pid = LLDB_INVALID_PROCESS_ID;
//
// Error lldb_error;
// // Sleep and wait a bit for debugserver to start to listen...
// char connect_url[128];
// ::snprintf (connect_url, sizeof(connect_url), "unix-accept://%s", unix_socket_name.c_str());
//
// // Spawn a new thread to accept incoming connection on the connect_url
// // so we can grab the pid from the inferior
// lldb::thread_t accept_thread = Host::ThreadCreate (unix_socket_name.c_str(),
// AcceptPIDFromInferior,
// connect_url,
// &lldb_error);
//
// ProcessSerialNumber psn;
// error = LSOpenURLsWithRole(urls.get(), kLSRolesShell, NULL, &app_params, &psn, 1);
// if (error == noErr)
// {
// thread_result_t accept_thread_result = NULL;
// if (Host::ThreadJoin (accept_thread, &accept_thread_result, &lldb_error))
// {
// if (accept_thread_result)
// {
// pid = (intptr_t)accept_thread_result;
//
// // Wait for process to be stopped the the entry point by watching
// // for the process status to be set to SSTOP which indicates it it
// // SIGSTOP'ed at the entry point
// WaitForProcessToSIGSTOP (pid, 5);
// }
// }
// }
// else
// {
// Host::ThreadCancel (accept_thread, &lldb_error);
// }
//
// return pid;
//}
Fixed all known race conditions with starting a process in a new terminal. We now spawn a thread to accept a unix socket connection from the inferior when it spawns in the terminal, then we launch the process, then we get the pid back through the unix socket, and then wait for it to SIGSTOP. darwin-debug now clears the terminal screen and prints out the program and arguments that are about to be launched. llvm-svn: 116841
2010-10-20 02:15:50 +08:00
Ok, last commit for the running processes in a new window. Now you can optionally specify the tty you want to use if you want to use an existing terminal window by giving a partial or full path name: (lldb) process launch --tty=ttys002 This would find the terminal window (or tab on MacOSX) that has ttys002 in its tty path and use it. If it isn't found, it will use a new terminal window. llvm-svn: 116878
2010-10-20 07:16:00 +08:00
const char *applscript_in_new_tty =
"tell application \"Terminal\"\n"
" do script \"%s\"\n"
"end tell\n";
const char *applscript_in_existing_tty = "\
set the_shell_script to \"%s\"\n\
tell application \"Terminal\"\n\
repeat with the_window in (get windows)\n\
repeat with the_tab in tabs of the_window\n\
set the_tty to tty in the_tab\n\
if the_tty contains \"%s\" then\n\
if the_tab is not busy then\n\
set selected of the_tab to true\n\
set frontmost of the_window to true\n\
do script the_shell_script in the_tab\n\
return\n\
end if\n\
end if\n\
end repeat\n\
end repeat\n\
do script the_shell_script\n\
end tell\n";
Fixed all known race conditions with starting a process in a new terminal. We now spawn a thread to accept a unix socket connection from the inferior when it spawns in the terminal, then we launch the process, then we get the pid back through the unix socket, and then wait for it to SIGSTOP. darwin-debug now clears the terminal screen and prints out the program and arguments that are about to be launched. llvm-svn: 116841
2010-10-20 02:15:50 +08:00
Moved many of the "settings" that used to be in "target.process.*" to just be in the target. All of the environment, args, stdin/out/err files, etc have all been moved. Also re-enabled the ability to launch a process in a separate terminal on MacOSX. llvm-svn: 144061
2011-11-08 10:43:13 +08:00
static Error
LaunchInNewTerminalWithAppleScript (const char *exe_path, ProcessLaunchInfo &launch_info)
{
Error error;
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
char unix_socket_name[PATH_MAX] = "/tmp/XXXXXX";
if (::mktemp (unix_socket_name) == NULL)
{
error.SetErrorString ("failed to make temporary path for a unix socket");
return error;
}
Fixed all known race conditions with starting a process in a new terminal. We now spawn a thread to accept a unix socket connection from the inferior when it spawns in the terminal, then we launch the process, then we get the pid back through the unix socket, and then wait for it to SIGSTOP. darwin-debug now clears the terminal screen and prints out the program and arguments that are about to be launched. llvm-svn: 116841
2010-10-20 02:15:50 +08:00
StreamString command;
FileSpec darwin_debug_file_spec;
if (!Host::GetLLDBPath (ePathTypeSupportExecutableDir, darwin_debug_file_spec))
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
{
error.SetErrorString ("can't locate the 'darwin-debug' executable");
return error;
}
Fixed all known race conditions with starting a process in a new terminal. We now spawn a thread to accept a unix socket connection from the inferior when it spawns in the terminal, then we launch the process, then we get the pid back through the unix socket, and then wait for it to SIGSTOP. darwin-debug now clears the terminal screen and prints out the program and arguments that are about to be launched. llvm-svn: 116841
2010-10-20 02:15:50 +08:00
darwin_debug_file_spec.GetFilename().SetCString("darwin-debug");
if (!darwin_debug_file_spec.Exists())
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
{
Cleanup logging to use the new "std::string FileSpec::GetPath()" function. Also added a similar function for modules: std::string Module::GetSpecificationDescription () const; This returns the module as "/usr/lib/libfoo.dylib" for normal files (calls "std::string FileSpec::GetPath()" on m_file) but it also might include the object name in case the module is for a .o file in a BSD archive ("/usr/lib/libfoo.a(bar.o)"). Cleaned up necessary logging code to use it. llvm-svn: 180717
2013-04-30 01:25:54 +08:00
error.SetErrorStringWithFormat ("the 'darwin-debug' executable doesn't exists at '%s'",
darwin_debug_file_spec.GetPath().c_str());
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
return error;
}
Fixed all known race conditions with starting a process in a new terminal. We now spawn a thread to accept a unix socket connection from the inferior when it spawns in the terminal, then we launch the process, then we get the pid back through the unix socket, and then wait for it to SIGSTOP. darwin-debug now clears the terminal screen and prints out the program and arguments that are about to be launched. llvm-svn: 116841
2010-10-20 02:15:50 +08:00
char launcher_path[PATH_MAX];
darwin_debug_file_spec.GetPath(launcher_path, sizeof(launcher_path));
Ok, last commit for the running processes in a new window. Now you can optionally specify the tty you want to use if you want to use an existing terminal window by giving a partial or full path name: (lldb) process launch --tty=ttys002 This would find the terminal window (or tab on MacOSX) that has ttys002 in its tty path and use it. If it isn't found, it will use a new terminal window. llvm-svn: 116878
2010-10-20 07:16:00 +08:00
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
const ArchSpec &arch_spec = launch_info.GetArchitecture();
if (arch_spec.IsValid())
command.Printf("arch -arch %s ", arch_spec.GetArchitectureName());
Fixed an issue where if you try and run something in a TTY that isn't the same architecture as a default program, the attach architecture auto detection would change the architecture to the architecture of the darwin-debug (which was always x86_64) and hose up your debug session. llvm-svn: 118399
2010-11-08 11:06:10 +08:00
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
command.Printf("'%s' --unix-socket=%s", launcher_path, unix_socket_name);
Fixed all known race conditions with starting a process in a new terminal. We now spawn a thread to accept a unix socket connection from the inferior when it spawns in the terminal, then we launch the process, then we get the pid back through the unix socket, and then wait for it to SIGSTOP. darwin-debug now clears the terminal screen and prints out the program and arguments that are about to be launched. llvm-svn: 116841
2010-10-20 02:15:50 +08:00
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
if (arch_spec.IsValid())
command.Printf(" --arch=%s", arch_spec.GetArchitectureName());
Fixed all known race conditions with starting a process in a new terminal. We now spawn a thread to accept a unix socket connection from the inferior when it spawns in the terminal, then we launch the process, then we get the pid back through the unix socket, and then wait for it to SIGSTOP. darwin-debug now clears the terminal screen and prints out the program and arguments that are about to be launched. llvm-svn: 116841
2010-10-20 02:15:50 +08:00
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
const char *working_dir = launch_info.GetWorkingDirectory();
Added a new variant of SBTarget::Launch() that deprectates the old one that takes separate file handles for stdin, stdout, and stder and also allows for the working directory to be specified. Added support to "process launch" to a new option: --working-dir=PATH. We can now set the working directory. If this is not set, it defaults to that of the process that has LLDB loaded. Added the working directory to the host LaunchInNewTerminal function to allows the current working directory to be set in processes that are spawned in their own terminal. Also hooked this up to the lldb_private::Process and all mac plug-ins. The linux plug-in had its API changed, but nothing is making use of it yet. Modfied "debugserver" and "darwin-debug" to also handle the current working directory options and modified the code in LLDB that spawns these tools to pass the info along. Fixed ProcessGDBRemote to properly pass along all file handles for stdin, stdout and stderr. After clearing the default values for the stdin/out/err file handles for process to be NULL, we had a crasher in UserSettingsController::UpdateStringVariable which is now fixed. Also fixed the setting of boolean values to be able to be set as "true", "yes", "on", "1" for true (case insensitive) and "false", "no", "off", or "0" for false. Fixed debugserver to properly handle files for STDIN, STDOUT and STDERR that are not already opened. Previous to this fix debugserver would only correctly open and dupe file handles for the slave side of a pseudo terminal. It now correctly handles getting STDIN for the inferior from a file, and spitting STDOUT and STDERR out to files. Also made sure the file handles were correctly opened with the NOCTTY flag for terminals. llvm-svn: 124060
2011-01-23 13:56:20 +08:00
if (working_dir)
command.Printf(" --working-dir '%s'", working_dir);
<rdar://problem/14083928> Making sure that if you invoke LLDB as lldb ./someBinary you can then launch the inferior with process launch —tty llvm-svn: 183453
2013-06-07 06:23:02 +08:00
else
{
char cwd[PATH_MAX];
if (getcwd(cwd, PATH_MAX))
command.Printf(" --working-dir '%s'", cwd);
}
Added a new variant of SBTarget::Launch() that deprectates the old one that takes separate file handles for stdin, stdout, and stder and also allows for the working directory to be specified. Added support to "process launch" to a new option: --working-dir=PATH. We can now set the working directory. If this is not set, it defaults to that of the process that has LLDB loaded. Added the working directory to the host LaunchInNewTerminal function to allows the current working directory to be set in processes that are spawned in their own terminal. Also hooked this up to the lldb_private::Process and all mac plug-ins. The linux plug-in had its API changed, but nothing is making use of it yet. Modfied "debugserver" and "darwin-debug" to also handle the current working directory options and modified the code in LLDB that spawns these tools to pass the info along. Fixed ProcessGDBRemote to properly pass along all file handles for stdin, stdout and stderr. After clearing the default values for the stdin/out/err file handles for process to be NULL, we had a crasher in UserSettingsController::UpdateStringVariable which is now fixed. Also fixed the setting of boolean values to be able to be set as "true", "yes", "on", "1" for true (case insensitive) and "false", "no", "off", or "0" for false. Fixed debugserver to properly handle files for STDIN, STDOUT and STDERR that are not already opened. Previous to this fix debugserver would only correctly open and dupe file handles for the slave side of a pseudo terminal. It now correctly handles getting STDIN for the inferior from a file, and spitting STDOUT and STDERR out to files. Also made sure the file handles were correctly opened with the NOCTTY flag for terminals. llvm-svn: 124060
2011-01-23 13:56:20 +08:00
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
if (launch_info.GetFlags().Test (eLaunchFlagDisableASLR))
Fixed all known race conditions with starting a process in a new terminal. We now spawn a thread to accept a unix socket connection from the inferior when it spawns in the terminal, then we launch the process, then we get the pid back through the unix socket, and then wait for it to SIGSTOP. darwin-debug now clears the terminal screen and prints out the program and arguments that are about to be launched. llvm-svn: 116841
2010-10-20 02:15:50 +08:00
command.PutCString(" --disable-aslr");
Moved many of the "settings" that used to be in "target.process.*" to just be in the target. All of the environment, args, stdin/out/err files, etc have all been moved. Also re-enabled the ability to launch a process in a separate terminal on MacOSX. llvm-svn: 144061
2011-11-08 10:43:13 +08:00
<rdar://problem/13665446> Pass the user set target.env-vars when launching through a terminal. llvm-svn: 180201
2013-04-25 01:53:59 +08:00
// We are launching on this host in a terminal. So compare the environemnt on the host
// to what is supplied in the launch_info. Any items that aren't in the host environemnt
// need to be sent to darwin-debug. If we send all environment entries, we might blow the
// max command line length, so we only send user modified entries.
const char **envp = launch_info.GetEnvironmentEntries().GetConstArgumentVector ();
StringList host_env;
const size_t host_env_count = Host::GetEnvironment (host_env);
const char *env_entry;
for (size_t env_idx = 0; (env_entry = envp[env_idx]) != NULL; ++env_idx)
{
bool add_entry = true;
for (size_t i=0; i<host_env_count; ++i)
{
const char *host_env_entry = host_env.GetStringAtIndex(i);
if (strcmp(env_entry, host_env_entry) == 0)
{
add_entry = false;
break;
}
}
if (add_entry)
{
command.Printf(" --env='%s'", env_entry);
}
}
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. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
command.PutCString(" -- ");
const char **argv = launch_info.GetArguments().GetConstArgumentVector ();
if (argv)
Fixed all known race conditions with starting a process in a new terminal. We now spawn a thread to accept a unix socket connection from the inferior when it spawns in the terminal, then we launch the process, then we get the pid back through the unix socket, and then wait for it to SIGSTOP. darwin-debug now clears the terminal screen and prints out the program and arguments that are about to be launched. llvm-svn: 116841
2010-10-20 02:15:50 +08:00
{
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. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
for (size_t i=0; argv[i] != NULL; ++i)
Moved many of the "settings" that used to be in "target.process.*" to just be in the target. All of the environment, args, stdin/out/err files, etc have all been moved. Also re-enabled the ability to launch a process in a separate terminal on MacOSX. llvm-svn: 144061
2011-11-08 10:43:13 +08:00
{
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. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
if (i==0)
command.Printf(" '%s'", exe_path);
else
command.Printf(" '%s'", argv[i]);
Moved many of the "settings" that used to be in "target.process.*" to just be in the target. All of the environment, args, stdin/out/err files, etc have all been moved. Also re-enabled the ability to launch a process in a separate terminal on MacOSX. llvm-svn: 144061
2011-11-08 10:43:13 +08:00
}
}
else
{
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. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
command.Printf(" '%s'", exe_path);
Fixed all known race conditions with starting a process in a new terminal. We now spawn a thread to accept a unix socket connection from the inferior when it spawns in the terminal, then we launch the process, then we get the pid back through the unix socket, and then wait for it to SIGSTOP. darwin-debug now clears the terminal screen and prints out the program and arguments that are about to be launched. llvm-svn: 116841
2010-10-20 02:15:50 +08:00
}
Ok, last commit for the running processes in a new window. Now you can optionally specify the tty you want to use if you want to use an existing terminal window by giving a partial or full path name: (lldb) process launch --tty=ttys002 This would find the terminal window (or tab on MacOSX) that has ttys002 in its tty path and use it. If it isn't found, it will use a new terminal window. llvm-svn: 116878
2010-10-20 07:16:00 +08:00
command.PutCString (" ; echo Process exited with status $?");
StreamString applescript_source;
Fixed an issue where if you try and run something in a TTY that isn't the same architecture as a default program, the attach architecture auto detection would change the architecture to the architecture of the darwin-debug (which was always x86_64) and hose up your debug session. llvm-svn: 118399
2010-11-08 11:06:10 +08:00
const char *tty_command = command.GetString().c_str();
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
// if (tty_name && tty_name[0])
// {
// applescript_source.Printf (applscript_in_existing_tty,
// tty_command,
// tty_name);
// }
// else
// {
Ok, last commit for the running processes in a new window. Now you can optionally specify the tty you want to use if you want to use an existing terminal window by giving a partial or full path name: (lldb) process launch --tty=ttys002 This would find the terminal window (or tab on MacOSX) that has ttys002 in its tty path and use it. If it isn't found, it will use a new terminal window. llvm-svn: 116878
2010-10-20 07:16:00 +08:00
applescript_source.Printf (applscript_in_new_tty,
Fixed an issue where if you try and run something in a TTY that isn't the same architecture as a default program, the attach architecture auto detection would change the architecture to the architecture of the darwin-debug (which was always x86_64) and hose up your debug session. llvm-svn: 118399
2010-11-08 11:06:10 +08:00
tty_command);
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
// }
Ok, last commit for the running processes in a new window. Now you can optionally specify the tty you want to use if you want to use an existing terminal window by giving a partial or full path name: (lldb) process launch --tty=ttys002 This would find the terminal window (or tab on MacOSX) that has ttys002 in its tty path and use it. If it isn't found, it will use a new terminal window. llvm-svn: 116878
2010-10-20 07:16:00 +08:00
const char *script_source = applescript_source.GetString().c_str();
//puts (script_source);
Fixed all known race conditions with starting a process in a new terminal. We now spawn a thread to accept a unix socket connection from the inferior when it spawns in the terminal, then we launch the process, then we get the pid back through the unix socket, and then wait for it to SIGSTOP. darwin-debug now clears the terminal screen and prints out the program and arguments that are about to be launched. llvm-svn: 116841
2010-10-20 02:15:50 +08:00
NSAppleScript* applescript = [[NSAppleScript alloc] initWithSource:[NSString stringWithCString:script_source encoding:NSUTF8StringEncoding]];
lldb::pid_t pid = LLDB_INVALID_PROCESS_ID;
Error lldb_error;
// Sleep and wait a bit for debugserver to start to listen...
ConnectionFileDescriptor file_conn;
char connect_url[128];
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
::snprintf (connect_url, sizeof(connect_url), "unix-accept://%s", unix_socket_name);
Fixed all known race conditions with starting a process in a new terminal. We now spawn a thread to accept a unix socket connection from the inferior when it spawns in the terminal, then we launch the process, then we get the pid back through the unix socket, and then wait for it to SIGSTOP. darwin-debug now clears the terminal screen and prints out the program and arguments that are about to be launched. llvm-svn: 116841
2010-10-20 02:15:50 +08:00
// Spawn a new thread to accept incoming connection on the connect_url
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
// so we can grab the pid from the inferior. We have to do this because we
// are sending an AppleScript that will launch a process in Terminal.app,
// in a shell and the shell will fork/exec a couple of times before we get
// to the process that we wanted to launch. So when our process actually
// gets launched, we will handshake with it and get the process ID for it.
lldb::thread_t accept_thread = Host::ThreadCreate (unix_socket_name,
Fixed all known race conditions with starting a process in a new terminal. We now spawn a thread to accept a unix socket connection from the inferior when it spawns in the terminal, then we launch the process, then we get the pid back through the unix socket, and then wait for it to SIGSTOP. darwin-debug now clears the terminal screen and prints out the program and arguments that are about to be launched. llvm-svn: 116841
2010-10-20 02:15:50 +08:00
AcceptPIDFromInferior,
connect_url,
&lldb_error);
[applescript executeAndReturnError:nil];
thread_result_t accept_thread_result = NULL;
if (Host::ThreadJoin (accept_thread, &accept_thread_result, &lldb_error))
{
if (accept_thread_result)
{
pid = (intptr_t)accept_thread_result;
// Wait for process to be stopped the the entry point by watching
// for the process status to be set to SSTOP which indicates it it
// SIGSTOP'ed at the entry point
WaitForProcessToSIGSTOP (pid, 5);
}
}
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
::unlink (unix_socket_name);
Fixed all known race conditions with starting a process in a new terminal. We now spawn a thread to accept a unix socket connection from the inferior when it spawns in the terminal, then we launch the process, then we get the pid back through the unix socket, and then wait for it to SIGSTOP. darwin-debug now clears the terminal screen and prints out the program and arguments that are about to be launched. llvm-svn: 116841
2010-10-20 02:15:50 +08:00
[applescript release];
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
if (pid != LLDB_INVALID_PROCESS_ID)
launch_info.SetProcessID (pid);
return error;
Cleaned up a unused member variable in Debugger. Added the start of Host specific launch services, though it currently isn't hookup up to anything. We want to be able to launch a process and use the native launch services to launch an app like it would be launched by the user double clicking on the app. We also eventually want to be able to run a command line app in a newly spawned terminal to avoid terminal sharing. Fixed an issue with the new DWARF forward type declaration stuff. A crasher was found that was happening when trying to properly expand the forward declarations. llvm-svn: 115213
2010-10-01 05:49:03 +08:00
}
Fixed all known race conditions with starting a process in a new terminal. We now spawn a thread to accept a unix socket connection from the inferior when it spawns in the terminal, then we launch the process, then we get the pid back through the unix socket, and then wait for it to SIGSTOP. darwin-debug now clears the terminal screen and prints out the program and arguments that are about to be launched. llvm-svn: 116841
2010-10-20 02:15:50 +08:00
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
#endif // #if !defined(__arm__)
Fixed all known race conditions with starting a process in a new terminal. We now spawn a thread to accept a unix socket connection from the inferior when it spawns in the terminal, then we launch the process, then we get the pid back through the unix socket, and then wait for it to SIGSTOP. darwin-debug now clears the terminal screen and prints out the program and arguments that are about to be launched. llvm-svn: 116841
2010-10-20 02:15:50 +08:00
Modified lldb_private::SymboleFile to be able to override where its TypeList comes from by using a virtual function to provide it from the Module's SymbolVendor by default. This allows the DWARF parser, when being used to parse DWARF in .o files with a parent DWARF + debug map parser, to get its type list from the DWARF + debug map parser so when we go and find full definitions for types (that might come from other .o files), we can use the type list from the debug map parser. Otherwise we ended up mixing clang types from one .o file (say a const pointer to a forward declaration "class A") with the a full type from another .o file. This causes expression parsing, when copying the clang types from those parsed by the DWARF parser into the expression AST, to fail -- for good reason. Now all types are created in the same list. Also added host support for crash description strings that can be set before doing a piece of work. On MacOSX, this ties in with CrashReporter support that allows a string to be dispalyed when the app crashes and allows LLDB.framework to print a description string in the crash log. Right now this is hookup up the the CommandInterpreter::HandleCommand() where each command notes that it is about to be executed, so if we crash while trying to do this command, we should be able to see the command that caused LLDB to exit. For all other platforms, this is a nop. llvm-svn: 118672
2010-11-10 12:57:04 +08:00
// On MacOSX CrashReporter will display a string for each shared library if
// the shared library has an exported symbol named "__crashreporter_info__".
static Mutex&
GetCrashReporterMutex ()
{
static Mutex g_mutex;
return g_mutex;
}
extern "C" {
const char *__crashreporter_info__ = NULL;
Fix the Host library build on Mac OS X with makefiles. llvm-svn: 131718
2011-05-20 12:04:17 +08:00
}
Modified lldb_private::SymboleFile to be able to override where its TypeList comes from by using a virtual function to provide it from the Module's SymbolVendor by default. This allows the DWARF parser, when being used to parse DWARF in .o files with a parent DWARF + debug map parser, to get its type list from the DWARF + debug map parser so when we go and find full definitions for types (that might come from other .o files), we can use the type list from the debug map parser. Otherwise we ended up mixing clang types from one .o file (say a const pointer to a forward declaration "class A") with the a full type from another .o file. This causes expression parsing, when copying the clang types from those parsed by the DWARF parser into the expression AST, to fail -- for good reason. Now all types are created in the same list. Also added host support for crash description strings that can be set before doing a piece of work. On MacOSX, this ties in with CrashReporter support that allows a string to be dispalyed when the app crashes and allows LLDB.framework to print a description string in the crash log. Right now this is hookup up the the CommandInterpreter::HandleCommand() where each command notes that it is about to be executed, so if we crash while trying to do this command, we should be able to see the command that caused LLDB to exit. For all other platforms, this is a nop. llvm-svn: 118672
2010-11-10 12:57:04 +08:00
asm(".desc ___crashreporter_info__, 0x10");
void
Host::SetCrashDescriptionWithFormat (const char *format, ...)
{
static StreamString g_crash_description;
Mutex::Locker locker (GetCrashReporterMutex ());
if (format)
{
va_list args;
va_start (args, format);
Don't keep appending to the current crash description with each formatted crash description call. llvm-svn: 118703
2010-11-11 03:43:40 +08:00
g_crash_description.GetString().clear();
Modified lldb_private::SymboleFile to be able to override where its TypeList comes from by using a virtual function to provide it from the Module's SymbolVendor by default. This allows the DWARF parser, when being used to parse DWARF in .o files with a parent DWARF + debug map parser, to get its type list from the DWARF + debug map parser so when we go and find full definitions for types (that might come from other .o files), we can use the type list from the debug map parser. Otherwise we ended up mixing clang types from one .o file (say a const pointer to a forward declaration "class A") with the a full type from another .o file. This causes expression parsing, when copying the clang types from those parsed by the DWARF parser into the expression AST, to fail -- for good reason. Now all types are created in the same list. Also added host support for crash description strings that can be set before doing a piece of work. On MacOSX, this ties in with CrashReporter support that allows a string to be dispalyed when the app crashes and allows LLDB.framework to print a description string in the crash log. Right now this is hookup up the the CommandInterpreter::HandleCommand() where each command notes that it is about to be executed, so if we crash while trying to do this command, we should be able to see the command that caused LLDB to exit. For all other platforms, this is a nop. llvm-svn: 118672
2010-11-10 12:57:04 +08:00
g_crash_description.PrintfVarArg(format, args);
va_end (args);
__crashreporter_info__ = g_crash_description.GetData();
}
else
{
__crashreporter_info__ = NULL;
}
}
void
Host::SetCrashDescription (const char *cstr)
{
Mutex::Locker locker (GetCrashReporterMutex ());
Made the Host::SetCrashDescription(const char *) function copy the incoming string to avoid possible later crashes. Modified the locations that do set the crash description to NULL out the string when they are done doing their tasks. llvm-svn: 144297
2011-11-11 02:31:53 +08:00
static std::string g_crash_description;
if (cstr)
{
g_crash_description.assign (cstr);
__crashreporter_info__ = g_crash_description.c_str();
}
else
{
__crashreporter_info__ = NULL;
}
Modified lldb_private::SymboleFile to be able to override where its TypeList comes from by using a virtual function to provide it from the Module's SymbolVendor by default. This allows the DWARF parser, when being used to parse DWARF in .o files with a parent DWARF + debug map parser, to get its type list from the DWARF + debug map parser so when we go and find full definitions for types (that might come from other .o files), we can use the type list from the debug map parser. Otherwise we ended up mixing clang types from one .o file (say a const pointer to a forward declaration "class A") with the a full type from another .o file. This causes expression parsing, when copying the clang types from those parsed by the DWARF parser into the expression AST, to fail -- for good reason. Now all types are created in the same list. Also added host support for crash description strings that can be set before doing a piece of work. On MacOSX, this ties in with CrashReporter support that allows a string to be dispalyed when the app crashes and allows LLDB.framework to print a description string in the crash log. Right now this is hookup up the the CommandInterpreter::HandleCommand() where each command notes that it is about to be executed, so if we crash while trying to do this command, we should be able to see the command that caused LLDB to exit. For all other platforms, this is a nop. llvm-svn: 118672
2010-11-10 12:57:04 +08:00
}
Cleaned up a unused member variable in Debugger. Added the start of Host specific launch services, though it currently isn't hookup up to anything. We want to be able to launch a process and use the native launch services to launch an app like it would be launched by the user double clicking on the app. We also eventually want to be able to run a command line app in a newly spawned terminal to avoid terminal sharing. Fixed an issue with the new DWARF forward type declaration stuff. A crasher was found that was happening when trying to properly expand the forward declarations. llvm-svn: 115213
2010-10-01 05:49:03 +08:00
Added a way to open the current source file & line in an external editor, and you can turn this on with: lldb -e llvm-svn: 112502
2010-08-31 03:44:40 +08:00
bool
Cleaned up a unused member variable in Debugger. Added the start of Host specific launch services, though it currently isn't hookup up to anything. We want to be able to launch a process and use the native launch services to launch an app like it would be launched by the user double clicking on the app. We also eventually want to be able to run a command line app in a newly spawned terminal to avoid terminal sharing. Fixed an issue with the new DWARF forward type declaration stuff. A crasher was found that was happening when trying to properly expand the forward declarations. llvm-svn: 115213
2010-10-01 05:49:03 +08:00
Host::OpenFileInExternalEditor (const FileSpec &file_spec, uint32_t line_no)
Added a way to open the current source file & line in an external editor, and you can turn this on with: lldb -e llvm-svn: 112502
2010-08-31 03:44:40 +08:00
{
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
#if defined(__arm__)
return false;
#else
Added a way to open the current source file & line in an external editor, and you can turn this on with: lldb -e llvm-svn: 112502
2010-08-31 03:44:40 +08:00
// We attach this to an 'odoc' event to specify a particular selection
typedef struct {
Stopped the external editor from adding stuff to the recent list when lldb is launched with the -e option on Mac OS X. llvm-svn: 112536
2010-08-31 06:00:34 +08:00
int16_t reserved0; // must be zero
int16_t fLineNumber;
int32_t fSelStart;
int32_t fSelEnd;
uint32_t reserved1; // must be zero
uint32_t reserved2; // must be zero
Added a way to open the current source file & line in an external editor, and you can turn this on with: lldb -e llvm-svn: 112502
2010-08-31 03:44:40 +08:00
} BabelAESelInfo;
<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. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAnyCategoriesSet (LIBLLDB_LOG_HOST));
Added a way to open the current source file & line in an external editor, and you can turn this on with: lldb -e llvm-svn: 112502
2010-08-31 03:44:40 +08:00
char file_path[PATH_MAX];
file_spec.GetPath(file_path, PATH_MAX);
CFCString file_cfstr (file_path, kCFStringEncodingUTF8);
Stopped the external editor from adding stuff to the recent list when lldb is launched with the -e option on Mac OS X. llvm-svn: 112536
2010-08-31 06:00:34 +08:00
CFCReleaser<CFURLRef> file_URL (::CFURLCreateWithFileSystemPath (NULL,
file_cfstr.get(),
kCFURLPOSIXPathStyle,
false));
Add a "lldb host" logging channel, and put logging in the Host::OpenInExternalEditor code. llvm-svn: 112614
2010-09-01 02:05:13 +08:00
if (log)
log->Printf("Sending source file: \"%s\" and line: %d to external editor.\n", file_path, line_no);
Stopped the external editor from adding stuff to the recent list when lldb is launched with the -e option on Mac OS X. llvm-svn: 112536
2010-08-31 06:00:34 +08:00
Expose new read memory fucntion through python in SBProcess: size_t SBProcess::ReadCStringFromMemory (addr_t addr, void *buf, size_t size, lldb::SBError &error); uint64_t SBProcess::ReadUnsignedFromMemory (addr_t addr, uint32_t byte_size, lldb::SBError &error); lldb::addr_t SBProcess::ReadPointerFromMemory (addr_t addr, lldb::SBError &error); These ReadCStringFromMemory() has some SWIG type magic that makes it return the python string directly and the "buf" is not needed: error = SBError() max_cstr_len = 256 cstr = lldb.process.ReadCStringFromMemory (0x1000, max_cstr_len, error) if error.Success(): .... The other two functions behave as expteced. This will make it easier to get integer values from the inferior process that are correctly byte swapped. Also for pointers, the correct pointer byte size will be used. Also cleaned up a few printf style warnings for the 32 bit lldb build on darwin. llvm-svn: 146636
2011-12-15 11:14:23 +08:00
long error;
Stopped the external editor from adding stuff to the recent list when lldb is launched with the -e option on Mac OS X. llvm-svn: 112536
2010-08-31 06:00:34 +08:00
BabelAESelInfo file_and_line_info =
{
Remove a ton of implicit narrowing conversions for C++11 compatibility. llvm-svn: 151071
2012-02-22 02:37:14 +08:00
0, // reserved0
(int16_t)(line_no - 1), // fLineNumber (zero based line number)
1, // fSelStart
1024, // fSelEnd
0, // reserved1
0 // reserved2
Stopped the external editor from adding stuff to the recent list when lldb is launched with the -e option on Mac OS X. llvm-svn: 112536
2010-08-31 06:00:34 +08:00
};
Added a way to open the current source file & line in an external editor, and you can turn this on with: lldb -e llvm-svn: 112502
2010-08-31 03:44:40 +08:00
AEKeyDesc file_and_line_desc;
Stopped the external editor from adding stuff to the recent list when lldb is launched with the -e option on Mac OS X. llvm-svn: 112536
2010-08-31 06:00:34 +08:00
error = ::AECreateDesc (typeUTF8Text,
&file_and_line_info,
sizeof (file_and_line_info),
&(file_and_line_desc.descContent));
Added a way to open the current source file & line in an external editor, and you can turn this on with: lldb -e llvm-svn: 112502
2010-08-31 03:44:40 +08:00
if (error != noErr)
{
Add a "lldb host" logging channel, and put logging in the Host::OpenInExternalEditor code. llvm-svn: 112614
2010-09-01 02:05:13 +08:00
if (log)
Expose new read memory fucntion through python in SBProcess: size_t SBProcess::ReadCStringFromMemory (addr_t addr, void *buf, size_t size, lldb::SBError &error); uint64_t SBProcess::ReadUnsignedFromMemory (addr_t addr, uint32_t byte_size, lldb::SBError &error); lldb::addr_t SBProcess::ReadPointerFromMemory (addr_t addr, lldb::SBError &error); These ReadCStringFromMemory() has some SWIG type magic that makes it return the python string directly and the "buf" is not needed: error = SBError() max_cstr_len = 256 cstr = lldb.process.ReadCStringFromMemory (0x1000, max_cstr_len, error) if error.Success(): .... The other two functions behave as expteced. This will make it easier to get integer values from the inferior process that are correctly byte swapped. Also for pointers, the correct pointer byte size will be used. Also cleaned up a few printf style warnings for the 32 bit lldb build on darwin. llvm-svn: 146636
2011-12-15 11:14:23 +08:00
log->Printf("Error creating AEDesc: %ld.\n", error);
Added a way to open the current source file & line in an external editor, and you can turn this on with: lldb -e llvm-svn: 112502
2010-08-31 03:44:40 +08:00
return false;
}
file_and_line_desc.descKey = keyAEPosition;
Cleaned up my previous submission which had some header search paths that were not needed and fixed a merge issue. llvm-svn: 112626
2010-09-01 02:56:24 +08:00
static std::string g_app_name;
Added the ability to disable ASLR (Address Space Layout Randomization). ASLR is disabled by default, and can be enabled using: (lldb) set disable-aslr 0 llvm-svn: 112616
2010-09-01 02:35:14 +08:00
static FSRef g_app_fsref;
Added a way to open the current source file & line in an external editor, and you can turn this on with: lldb -e llvm-svn: 112502
2010-08-31 03:44:40 +08:00
LSApplicationParameters app_params;
Remove bzero use and replace with memset (patch from Kirk Beitz). llvm-svn: 124897
2011-02-05 05:13:05 +08:00
::memset (&app_params, 0, sizeof (app_params));
Stopped the external editor from adding stuff to the recent list when lldb is launched with the -e option on Mac OS X. llvm-svn: 112536
2010-08-31 06:00:34 +08:00
app_params.flags = kLSLaunchDefaults |
kLSLaunchDontAddToRecents |
kLSLaunchDontSwitch;
Added the ability to disable ASLR (Address Space Layout Randomization). ASLR is disabled by default, and can be enabled using: (lldb) set disable-aslr 0 llvm-svn: 112616
2010-09-01 02:35:14 +08:00
Add LLDB_EXTERNAL_EDITOR llvm-svn: 112558
2010-08-31 07:48:25 +08:00
char *external_editor = ::getenv ("LLDB_EXTERNAL_EDITOR");
Added the ability to disable ASLR (Address Space Layout Randomization). ASLR is disabled by default, and can be enabled using: (lldb) set disable-aslr 0 llvm-svn: 112616
2010-09-01 02:35:14 +08:00
if (external_editor)
Add LLDB_EXTERNAL_EDITOR llvm-svn: 112558
2010-08-31 07:48:25 +08:00
{
Add a "lldb host" logging channel, and put logging in the Host::OpenInExternalEditor code. llvm-svn: 112614
2010-09-01 02:05:13 +08:00
if (log)
log->Printf("Looking for external editor \"%s\".\n", external_editor);
Cleaned up my previous submission which had some header search paths that were not needed and fixed a merge issue. llvm-svn: 112626
2010-09-01 02:56:24 +08:00
if (g_app_name.empty() || strcmp (g_app_name.c_str(), external_editor) != 0)
Add LLDB_EXTERNAL_EDITOR llvm-svn: 112558
2010-08-31 07:48:25 +08:00
{
CFCString editor_name (external_editor, kCFStringEncodingUTF8);
Added the ability to disable ASLR (Address Space Layout Randomization). ASLR is disabled by default, and can be enabled using: (lldb) set disable-aslr 0 llvm-svn: 112616
2010-09-01 02:35:14 +08:00
error = ::LSFindApplicationForInfo (kLSUnknownCreator,
NULL,
editor_name.get(),
&g_app_fsref,
NULL);
Add LLDB_EXTERNAL_EDITOR llvm-svn: 112558
2010-08-31 07:48:25 +08:00
// If we found the app, then store away the name so we don't have to re-look it up.
Added the ability to disable ASLR (Address Space Layout Randomization). ASLR is disabled by default, and can be enabled using: (lldb) set disable-aslr 0 llvm-svn: 112616
2010-09-01 02:35:14 +08:00
if (error != noErr)
Add a "lldb host" logging channel, and put logging in the Host::OpenInExternalEditor code. llvm-svn: 112614
2010-09-01 02:05:13 +08:00
{
if (log)
Expose new read memory fucntion through python in SBProcess: size_t SBProcess::ReadCStringFromMemory (addr_t addr, void *buf, size_t size, lldb::SBError &error); uint64_t SBProcess::ReadUnsignedFromMemory (addr_t addr, uint32_t byte_size, lldb::SBError &error); lldb::addr_t SBProcess::ReadPointerFromMemory (addr_t addr, lldb::SBError &error); These ReadCStringFromMemory() has some SWIG type magic that makes it return the python string directly and the "buf" is not needed: error = SBError() max_cstr_len = 256 cstr = lldb.process.ReadCStringFromMemory (0x1000, max_cstr_len, error) if error.Success(): .... The other two functions behave as expteced. This will make it easier to get integer values from the inferior process that are correctly byte swapped. Also for pointers, the correct pointer byte size will be used. Also cleaned up a few printf style warnings for the 32 bit lldb build on darwin. llvm-svn: 146636
2011-12-15 11:14:23 +08:00
log->Printf("Could not find External Editor application, error: %ld.\n", error);
Add LLDB_EXTERNAL_EDITOR llvm-svn: 112558
2010-08-31 07:48:25 +08:00
return false;
Add a "lldb host" logging channel, and put logging in the Host::OpenInExternalEditor code. llvm-svn: 112614
2010-09-01 02:05:13 +08:00
}
Add LLDB_EXTERNAL_EDITOR llvm-svn: 112558
2010-08-31 07:48:25 +08:00
}
Added the ability to disable ASLR (Address Space Layout Randomization). ASLR is disabled by default, and can be enabled using: (lldb) set disable-aslr 0 llvm-svn: 112616
2010-09-01 02:35:14 +08:00
app_params.application = &g_app_fsref;
Add LLDB_EXTERNAL_EDITOR llvm-svn: 112558
2010-08-31 07:48:25 +08:00
}
Added a way to open the current source file & line in an external editor, and you can turn this on with: lldb -e llvm-svn: 112502
2010-08-31 03:44:40 +08:00
ProcessSerialNumber psn;
CFCReleaser<CFArrayRef> file_array(CFArrayCreate (NULL, (const void **) file_URL.ptr_address(false), 1, NULL));
Stopped the external editor from adding stuff to the recent list when lldb is launched with the -e option on Mac OS X. llvm-svn: 112536
2010-08-31 06:00:34 +08:00
error = ::LSOpenURLsWithRole (file_array.get(),
Add LLDB_EXTERNAL_EDITOR llvm-svn: 112558
2010-08-31 07:48:25 +08:00
kLSRolesAll,
Stopped the external editor from adding stuff to the recent list when lldb is launched with the -e option on Mac OS X. llvm-svn: 112536
2010-08-31 06:00:34 +08:00
&file_and_line_desc,
&app_params,
&psn,
1);
Added a way to open the current source file & line in an external editor, and you can turn this on with: lldb -e llvm-svn: 112502
2010-08-31 03:44:40 +08:00
AEDisposeDesc (&(file_and_line_desc.descContent));
if (error != noErr)
{
Add a "lldb host" logging channel, and put logging in the Host::OpenInExternalEditor code. llvm-svn: 112614
2010-09-01 02:05:13 +08:00
if (log)
Expose new read memory fucntion through python in SBProcess: size_t SBProcess::ReadCStringFromMemory (addr_t addr, void *buf, size_t size, lldb::SBError &error); uint64_t SBProcess::ReadUnsignedFromMemory (addr_t addr, uint32_t byte_size, lldb::SBError &error); lldb::addr_t SBProcess::ReadPointerFromMemory (addr_t addr, lldb::SBError &error); These ReadCStringFromMemory() has some SWIG type magic that makes it return the python string directly and the "buf" is not needed: error = SBError() max_cstr_len = 256 cstr = lldb.process.ReadCStringFromMemory (0x1000, max_cstr_len, error) if error.Success(): .... The other two functions behave as expteced. This will make it easier to get integer values from the inferior process that are correctly byte swapped. Also for pointers, the correct pointer byte size will be used. Also cleaned up a few printf style warnings for the 32 bit lldb build on darwin. llvm-svn: 146636
2011-12-15 11:14:23 +08:00
log->Printf("LSOpenURLsWithRole failed, error: %ld.\n", error);
Add a "lldb host" logging channel, and put logging in the Host::OpenInExternalEditor code. llvm-svn: 112614
2010-09-01 02:05:13 +08:00
Added a way to open the current source file & line in an external editor, and you can turn this on with: lldb -e llvm-svn: 112502
2010-08-31 03:44:40 +08:00
return false;
}
ProcessInfoRec which_process;
Remove bzero use and replace with memset (patch from Kirk Beitz). llvm-svn: 124897
2011-02-05 05:13:05 +08:00
::memset(&which_process, 0, sizeof(which_process));
Added a way to open the current source file & line in an external editor, and you can turn this on with: lldb -e llvm-svn: 112502
2010-08-31 03:44:40 +08:00
unsigned char ap_name[PATH_MAX];
which_process.processName = ap_name;
Stopped the external editor from adding stuff to the recent list when lldb is launched with the -e option on Mac OS X. llvm-svn: 112536
2010-08-31 06:00:34 +08:00
error = ::GetProcessInformation (&psn, &which_process);
Added a way to open the current source file & line in an external editor, and you can turn this on with: lldb -e llvm-svn: 112502
2010-08-31 03:44:40 +08:00
Add a "lldb host" logging channel, and put logging in the Host::OpenInExternalEditor code. llvm-svn: 112614
2010-09-01 02:05:13 +08:00
bool using_xcode;
if (error != noErr)
{
if (log)
Expose new read memory fucntion through python in SBProcess: size_t SBProcess::ReadCStringFromMemory (addr_t addr, void *buf, size_t size, lldb::SBError &error); uint64_t SBProcess::ReadUnsignedFromMemory (addr_t addr, uint32_t byte_size, lldb::SBError &error); lldb::addr_t SBProcess::ReadPointerFromMemory (addr_t addr, lldb::SBError &error); These ReadCStringFromMemory() has some SWIG type magic that makes it return the python string directly and the "buf" is not needed: error = SBError() max_cstr_len = 256 cstr = lldb.process.ReadCStringFromMemory (0x1000, max_cstr_len, error) if error.Success(): .... The other two functions behave as expteced. This will make it easier to get integer values from the inferior process that are correctly byte swapped. Also for pointers, the correct pointer byte size will be used. Also cleaned up a few printf style warnings for the 32 bit lldb build on darwin. llvm-svn: 146636
2011-12-15 11:14:23 +08:00
log->Printf("GetProcessInformation failed, error: %ld.\n", error);
Add a "lldb host" logging channel, and put logging in the Host::OpenInExternalEditor code. llvm-svn: 112614
2010-09-01 02:05:13 +08:00
using_xcode = false;
}
else
using_xcode = strncmp((char *) ap_name+1, "Xcode", (int) ap_name[0]) == 0;
Added a way to open the current source file & line in an external editor, and you can turn this on with: lldb -e llvm-svn: 112502
2010-08-31 03:44:40 +08:00
// Xcode doesn't obey the line number in the Open Apple Event. So I have to send
// it an AppleScript to focus on the right line.
if (using_xcode)
{
static ComponentInstance osa_component = NULL;
static const char *as_template = "tell application \"Xcode\"\n"
"set doc to the first document whose path is \"%s\"\n"
"set the selection to paragraph %d of doc\n"
"--- set the selected paragraph range to {%d, %d} of doc\n"
"end tell\n";
const int chars_for_int = 32;
static int as_template_len = strlen (as_template);
char *as_str;
AEDesc as_desc;
if (osa_component == NULL)
{
Stopped the external editor from adding stuff to the recent list when lldb is launched with the -e option on Mac OS X. llvm-svn: 112536
2010-08-31 06:00:34 +08:00
osa_component = ::OpenDefaultComponent (kOSAComponentType,
kAppleScriptSubtype);
Added a way to open the current source file & line in an external editor, and you can turn this on with: lldb -e llvm-svn: 112502
2010-08-31 03:44:40 +08:00
}
if (osa_component == NULL)
{
Add a "lldb host" logging channel, and put logging in the Host::OpenInExternalEditor code. llvm-svn: 112614
2010-09-01 02:05:13 +08:00
if (log)
log->Printf("Could not get default AppleScript component.\n");
Added a way to open the current source file & line in an external editor, and you can turn this on with: lldb -e llvm-svn: 112502
2010-08-31 03:44:40 +08:00
return false;
}
uint32_t as_str_size = as_template_len + strlen (file_path) + 3 * chars_for_int + 1;
as_str = (char *) malloc (as_str_size);
Stopped the external editor from adding stuff to the recent list when lldb is launched with the -e option on Mac OS X. llvm-svn: 112536
2010-08-31 06:00:34 +08:00
::snprintf (as_str,
as_str_size - 1,
as_template,
file_path,
line_no,
line_no,
line_no);
error = ::AECreateDesc (typeChar,
as_str,
strlen (as_str),
&as_desc);
::free (as_str);
Added a way to open the current source file & line in an external editor, and you can turn this on with: lldb -e llvm-svn: 112502
2010-08-31 03:44:40 +08:00
if (error != noErr)
Add a "lldb host" logging channel, and put logging in the Host::OpenInExternalEditor code. llvm-svn: 112614
2010-09-01 02:05:13 +08:00
{
if (log)
Expose new read memory fucntion through python in SBProcess: size_t SBProcess::ReadCStringFromMemory (addr_t addr, void *buf, size_t size, lldb::SBError &error); uint64_t SBProcess::ReadUnsignedFromMemory (addr_t addr, uint32_t byte_size, lldb::SBError &error); lldb::addr_t SBProcess::ReadPointerFromMemory (addr_t addr, lldb::SBError &error); These ReadCStringFromMemory() has some SWIG type magic that makes it return the python string directly and the "buf" is not needed: error = SBError() max_cstr_len = 256 cstr = lldb.process.ReadCStringFromMemory (0x1000, max_cstr_len, error) if error.Success(): .... The other two functions behave as expteced. This will make it easier to get integer values from the inferior process that are correctly byte swapped. Also for pointers, the correct pointer byte size will be used. Also cleaned up a few printf style warnings for the 32 bit lldb build on darwin. llvm-svn: 146636
2011-12-15 11:14:23 +08:00
log->Printf("Failed to create AEDesc for Xcode AppleEvent: %ld.\n", error);
Added a way to open the current source file & line in an external editor, and you can turn this on with: lldb -e llvm-svn: 112502
2010-08-31 03:44:40 +08:00
return false;
Add a "lldb host" logging channel, and put logging in the Host::OpenInExternalEditor code. llvm-svn: 112614
2010-09-01 02:05:13 +08:00
}
Added a way to open the current source file & line in an external editor, and you can turn this on with: lldb -e llvm-svn: 112502
2010-08-31 03:44:40 +08:00
OSAID ret_OSAID;
Stopped the external editor from adding stuff to the recent list when lldb is launched with the -e option on Mac OS X. llvm-svn: 112536
2010-08-31 06:00:34 +08:00
error = ::OSACompileExecute (osa_component,
&as_desc,
kOSANullScript,
kOSAModeNeverInteract,
&ret_OSAID);
::OSADispose (osa_component, ret_OSAID);
Added a way to open the current source file & line in an external editor, and you can turn this on with: lldb -e llvm-svn: 112502
2010-08-31 03:44:40 +08:00
Stopped the external editor from adding stuff to the recent list when lldb is launched with the -e option on Mac OS X. llvm-svn: 112536
2010-08-31 06:00:34 +08:00
::AEDisposeDesc (&as_desc);
Added a way to open the current source file & line in an external editor, and you can turn this on with: lldb -e llvm-svn: 112502
2010-08-31 03:44:40 +08:00
if (error != noErr)
Add a "lldb host" logging channel, and put logging in the Host::OpenInExternalEditor code. llvm-svn: 112614
2010-09-01 02:05:13 +08:00
{
if (log)
Expose new read memory fucntion through python in SBProcess: size_t SBProcess::ReadCStringFromMemory (addr_t addr, void *buf, size_t size, lldb::SBError &error); uint64_t SBProcess::ReadUnsignedFromMemory (addr_t addr, uint32_t byte_size, lldb::SBError &error); lldb::addr_t SBProcess::ReadPointerFromMemory (addr_t addr, lldb::SBError &error); These ReadCStringFromMemory() has some SWIG type magic that makes it return the python string directly and the "buf" is not needed: error = SBError() max_cstr_len = 256 cstr = lldb.process.ReadCStringFromMemory (0x1000, max_cstr_len, error) if error.Success(): .... The other two functions behave as expteced. This will make it easier to get integer values from the inferior process that are correctly byte swapped. Also for pointers, the correct pointer byte size will be used. Also cleaned up a few printf style warnings for the 32 bit lldb build on darwin. llvm-svn: 146636
2011-12-15 11:14:23 +08:00
log->Printf("Sending AppleEvent to Xcode failed, error: %ld.\n", error);
Added a way to open the current source file & line in an external editor, and you can turn this on with: lldb -e llvm-svn: 112502
2010-08-31 03:44:40 +08:00
return false;
Add a "lldb host" logging channel, and put logging in the Host::OpenInExternalEditor code. llvm-svn: 112614
2010-09-01 02:05:13 +08:00
}
Added a way to open the current source file & line in an external editor, and you can turn this on with: lldb -e llvm-svn: 112502
2010-08-31 03:44:40 +08:00
}
return true;
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
#endif // #if !defined(__arm__)
Added a way to open the current source file & line in an external editor, and you can turn this on with: lldb -e llvm-svn: 112502
2010-08-31 03:44:40 +08:00
}
Fixed a race condition that could cause ProcessGDBRemote::DoResume() to return an error saying the resume timed out. Previously the thread that was trying to resume the process would eventually call ProcessGDBRemote::DoResume() which would broadcast an event over to the async GDB remote thread which would sent the continue packet to the remote gdb server. Right after this was sent, it would set a predicate boolean value (protected by a mutex and condition) and then the thread that issued the ProcessGDBRemote::DoResume() would then wait for that condition variable to be set. If the async gdb thread was too quick though, the predicate boolean value could have been set to true and back to false by the time the thread that issued the ProcessGDBRemote::DoResume() checks the boolean value. So we can't use the predicate value as a handshake. I have changed the code over to using a Event by having the GDB remote communication object post an event: GDBRemoteCommunication::eBroadcastBitRunPacketSent This allows reliable handshaking between the two threads and avoids the erroneous ProcessGDBRemote::DoResume() errors. Added a host backtrace service to allow in process backtraces when trying to track down tricky issues. I need to see if LLVM has any backtracing abilities abstracted in it already, and if so, use that, but I needed something ASAP for the current issue I was working on. The static function is: void Host::Backtrace (Stream &strm, uint32_t max_frames); And it will backtrace at most "max_frames" frames for the current thread and can be used with any of the Stream subclasses for logging. llvm-svn: 120793
2010-12-03 14:02:24 +08:00
void
Host::Backtrace (Stream &strm, uint32_t max_frames)
{
Don't log to a temp file and delete it, just use the API that gives us a malloc'ed string array. llvm-svn: 153785
2012-03-31 07:47:35 +08:00
if (max_frames > 0)
Fixed a race condition that could cause ProcessGDBRemote::DoResume() to return an error saying the resume timed out. Previously the thread that was trying to resume the process would eventually call ProcessGDBRemote::DoResume() which would broadcast an event over to the async GDB remote thread which would sent the continue packet to the remote gdb server. Right after this was sent, it would set a predicate boolean value (protected by a mutex and condition) and then the thread that issued the ProcessGDBRemote::DoResume() would then wait for that condition variable to be set. If the async gdb thread was too quick though, the predicate boolean value could have been set to true and back to false by the time the thread that issued the ProcessGDBRemote::DoResume() checks the boolean value. So we can't use the predicate value as a handshake. I have changed the code over to using a Event by having the GDB remote communication object post an event: GDBRemoteCommunication::eBroadcastBitRunPacketSent This allows reliable handshaking between the two threads and avoids the erroneous ProcessGDBRemote::DoResume() errors. Added a host backtrace service to allow in process backtraces when trying to track down tricky issues. I need to see if LLVM has any backtracing abilities abstracted in it already, and if so, use that, but I needed something ASAP for the current issue I was working on. The static function is: void Host::Backtrace (Stream &strm, uint32_t max_frames); And it will backtrace at most "max_frames" frames for the current thread and can be used with any of the Stream subclasses for logging. llvm-svn: 120793
2010-12-03 14:02:24 +08:00
{
std::vector<void *> frame_buffer (max_frames, NULL);
Don't log to a temp file and delete it, just use the API that gives us a malloc'ed string array. llvm-svn: 153785
2012-03-31 07:47:35 +08:00
int num_frames = ::backtrace (&frame_buffer[0], frame_buffer.size());
char** strs = ::backtrace_symbols (&frame_buffer[0], num_frames);
if (strs)
Fixed a race condition that could cause ProcessGDBRemote::DoResume() to return an error saying the resume timed out. Previously the thread that was trying to resume the process would eventually call ProcessGDBRemote::DoResume() which would broadcast an event over to the async GDB remote thread which would sent the continue packet to the remote gdb server. Right after this was sent, it would set a predicate boolean value (protected by a mutex and condition) and then the thread that issued the ProcessGDBRemote::DoResume() would then wait for that condition variable to be set. If the async gdb thread was too quick though, the predicate boolean value could have been set to true and back to false by the time the thread that issued the ProcessGDBRemote::DoResume() checks the boolean value. So we can't use the predicate value as a handshake. I have changed the code over to using a Event by having the GDB remote communication object post an event: GDBRemoteCommunication::eBroadcastBitRunPacketSent This allows reliable handshaking between the two threads and avoids the erroneous ProcessGDBRemote::DoResume() errors. Added a host backtrace service to allow in process backtraces when trying to track down tricky issues. I need to see if LLVM has any backtracing abilities abstracted in it already, and if so, use that, but I needed something ASAP for the current issue I was working on. The static function is: void Host::Backtrace (Stream &strm, uint32_t max_frames); And it will backtrace at most "max_frames" frames for the current thread and can be used with any of the Stream subclasses for logging. llvm-svn: 120793
2010-12-03 14:02:24 +08:00
{
Don't log to a temp file and delete it, just use the API that gives us a malloc'ed string array. llvm-svn: 153785
2012-03-31 07:47:35 +08:00
// Start at 1 to skip the "Host::Backtrace" frame
for (int i = 1; i < num_frames; ++i)
strm.Printf("%s\n", strs[i]);
::free (strs);
Fixed a race condition that could cause ProcessGDBRemote::DoResume() to return an error saying the resume timed out. Previously the thread that was trying to resume the process would eventually call ProcessGDBRemote::DoResume() which would broadcast an event over to the async GDB remote thread which would sent the continue packet to the remote gdb server. Right after this was sent, it would set a predicate boolean value (protected by a mutex and condition) and then the thread that issued the ProcessGDBRemote::DoResume() would then wait for that condition variable to be set. If the async gdb thread was too quick though, the predicate boolean value could have been set to true and back to false by the time the thread that issued the ProcessGDBRemote::DoResume() checks the boolean value. So we can't use the predicate value as a handshake. I have changed the code over to using a Event by having the GDB remote communication object post an event: GDBRemoteCommunication::eBroadcastBitRunPacketSent This allows reliable handshaking between the two threads and avoids the erroneous ProcessGDBRemote::DoResume() errors. Added a host backtrace service to allow in process backtraces when trying to track down tricky issues. I need to see if LLVM has any backtracing abilities abstracted in it already, and if so, use that, but I needed something ASAP for the current issue I was working on. The static function is: void Host::Backtrace (Stream &strm, uint32_t max_frames); And it will backtrace at most "max_frames" frames for the current thread and can be used with any of the Stream subclasses for logging. llvm-svn: 120793
2010-12-03 14:02:24 +08:00
}
}
}
Added the ability for a process to inherit the current host environment. This was done as an settings variable in the process for now. We will eventually move all environment stuff over to the target, but we will leave it with the process for now. The default setting is for a process to inherit the host environment. This can be disabled by setting the "inherit-env" setting to false in the process. llvm-svn: 120862
2010-12-04 08:10:17 +08:00
size_t
Host::GetEnvironment (StringList &env)
{
char **host_env = *_NSGetEnviron();
char *env_entry;
size_t i;
for (i=0; (env_entry = host_env[i]) != NULL; ++i)
env.AppendString(env_entry);
return i;
}
Added more platform support. There are now some new commands: 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
2011-03-19 09:12:21 +08:00
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. llvm-svn: 128193
2011-03-24 12:28:38 +08:00
bool
Host::GetOSBuildString (std::string &s)
{
int mib[2] = { CTL_KERN, KERN_OSVERSION };
char cstr[PATH_MAX];
size_t cstr_len = sizeof(cstr);
if (::sysctl (mib, 2, cstr, &cstr_len, NULL, 0) == 0)
{
s.assign (cstr, cstr_len);
return true;
}
s.clear();
return false;
}
bool
Host::GetOSKernelDescription (std::string &s)
{
int mib[2] = { CTL_KERN, KERN_VERSION };
char cstr[PATH_MAX];
size_t cstr_len = sizeof(cstr);
if (::sysctl (mib, 2, cstr, &cstr_len, NULL, 0) == 0)
{
s.assign (cstr, cstr_len);
return true;
}
s.clear();
return false;
}
Unify how we get host version on Mac OS X & iOS. Also remove our dependency on UIKit & AppKit. Cleaned up the project files a bit. <rdar://problem/11814498> llvm-svn: 160147
2012-07-13 07:16:43 +08:00
#include <libxml/parser.h>
#include <libxml/tree.h>
Added more platform support. There are now some new commands: 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
2011-03-19 09:12:21 +08:00
bool
Host::GetOSVersion
(
uint32_t &major,
uint32_t &minor,
uint32_t &update
)
{
Unify how we get host version on Mac OS X & iOS. Also remove our dependency on UIKit & AppKit. Cleaned up the project files a bit. <rdar://problem/11814498> llvm-svn: 160147
2012-07-13 07:16:43 +08:00
static const char *version_plist_file = "/System/Library/CoreServices/SystemVersion.plist";
char buffer[256];
const char *product_version_str = NULL;
CFCReleaser<CFURLRef> plist_url(CFURLCreateFromFileSystemRepresentation(kCFAllocatorDefault,
(UInt8 *) version_plist_file,
strlen (version_plist_file), NO));
if (plist_url.get())
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
{
Unify how we get host version on Mac OS X & iOS. Also remove our dependency on UIKit & AppKit. Cleaned up the project files a bit. <rdar://problem/11814498> llvm-svn: 160147
2012-07-13 07:16:43 +08:00
CFCReleaser<CFPropertyListRef> property_list;
CFCReleaser<CFStringRef> error_string;
CFCReleaser<CFDataRef> resource_data;
SInt32 error_code;
// Read the XML file.
Ran the static analyzer on the codebase and found a few things. llvm-svn: 160338
2012-07-17 11:23:13 +08:00
if (CFURLCreateDataAndPropertiesFromResource (kCFAllocatorDefault,
plist_url.get(),
resource_data.ptr_address(),
NULL,
NULL,
&error_code))
Unify how we get host version on Mac OS X & iOS. Also remove our dependency on UIKit & AppKit. Cleaned up the project files a bit. <rdar://problem/11814498> llvm-svn: 160147
2012-07-13 07:16:43 +08:00
{
Ran the static analyzer on the codebase and found a few things. llvm-svn: 160338
2012-07-17 11:23:13 +08:00
// Reconstitute the dictionary using the XML data.
property_list = CFPropertyListCreateFromXMLData (kCFAllocatorDefault,
resource_data.get(),
kCFPropertyListImmutable,
error_string.ptr_address());
if (CFGetTypeID(property_list.get()) == CFDictionaryGetTypeID())
Unify how we get host version on Mac OS X & iOS. Also remove our dependency on UIKit & AppKit. Cleaned up the project files a bit. <rdar://problem/11814498> llvm-svn: 160147
2012-07-13 07:16:43 +08:00
{
Ran the static analyzer on the codebase and found a few things. llvm-svn: 160338
2012-07-17 11:23:13 +08:00
CFDictionaryRef property_dict = (CFDictionaryRef) property_list.get();
CFStringRef product_version_key = CFSTR("ProductVersion");
CFPropertyListRef product_version_value;
product_version_value = CFDictionaryGetValue(property_dict, product_version_key);
if (product_version_value && CFGetTypeID(product_version_value) == CFStringGetTypeID())
{
CFStringRef product_version_cfstr = (CFStringRef) product_version_value;
product_version_str = CFStringGetCStringPtr(product_version_cfstr, kCFStringEncodingUTF8);
Fixed a potential crash in the GetOSVersion code caused by a CFStringRef going out of scope. llvm-svn: 186912
2013-07-23 09:38:41 +08:00
if (product_version_str != NULL) {
Ran the static analyzer on the codebase and found a few things. llvm-svn: 160338
2012-07-17 11:23:13 +08:00
if (CFStringGetCString(product_version_cfstr, buffer, 256, kCFStringEncodingUTF8))
product_version_str = buffer;
}
Unify how we get host version on Mac OS X & iOS. Also remove our dependency on UIKit & AppKit. Cleaned up the project files a bit. <rdar://problem/11814498> llvm-svn: 160147
2012-07-13 07:16:43 +08:00
}
}
}
Fixed the Xcode project building of LLVM to be a bit more user friendly: - If you download and build the sources in the Xcode project, x86_64 builds by default using the "llvm.zip" checkpointed LLVM. - If you delete the "lldb/llvm.zip" and the "lldb/llvm" folder, and build the Xcode project will download the right LLVM sources and build them from scratch - If you have a "lldb/llvm" folder already that contains a "lldb/llvm/lib" directory, we will use the sources you have placed in the LLDB directory. Python can now be disabled for platforms that don't support it. Changed the way the libllvmclang.a files get used. They now all get built into arch specific directories and never get merged into universal binaries as this was causing issues where you would have to go and delete the file if you wanted to build an extra architecture slice. llvm-svn: 143678
2011-11-04 11:34:56 +08:00
}
Added more platform support. There are now some new commands: 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
2011-03-19 09:12:21 +08:00
Unify how we get host version on Mac OS X & iOS. Also remove our dependency on UIKit & AppKit. Cleaned up the project files a bit. <rdar://problem/11814498> llvm-svn: 160147
2012-07-13 07:16:43 +08:00
if (product_version_str)
Added more platform support. There are now some new commands: 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
2011-03-19 09:12:21 +08:00
{
Unify how we get host version on Mac OS X & iOS. Also remove our dependency on UIKit & AppKit. Cleaned up the project files a bit. <rdar://problem/11814498> llvm-svn: 160147
2012-07-13 07:16:43 +08:00
Args::StringToVersion(product_version_str, major, minor, update);
return true;
Added more platform support. There are now some new commands: 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
2011-03-19 09:12:21 +08:00
}
else
Unify how we get host version on Mac OS X & iOS. Also remove our dependency on UIKit & AppKit. Cleaned up the project files a bit. <rdar://problem/11814498> llvm-svn: 160147
2012-07-13 07:16:43 +08:00
return false;
Added more platform support. There are now some new commands: 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
2011-03-19 09:12:21 +08:00
}
Added real user/group id, effective user/group id, and parent process ID to the ProcessInfo. llvm-svn: 128023
2011-03-22 05:25:07 +08:00
static bool
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
GetMacOSXProcessName (const ProcessInstanceInfoMatch *match_info_ptr,
ProcessInstanceInfo &process_info)
Added real user/group id, effective user/group id, and parent process ID to the ProcessInfo. llvm-svn: 128023
2011-03-22 05:25:07 +08:00
{
if (process_info.ProcessIDIsValid())
{
char process_name[MAXCOMLEN * 2 + 1];
int name_len = ::proc_name(process_info.GetProcessID(), process_name, MAXCOMLEN * 2);
if (name_len == 0)
return false;
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; llvm-svn: 128563
2011-03-31 02:16:51 +08:00
if (match_info_ptr == NULL || NameMatches(process_name,
match_info_ptr->GetNameMatchType(),
match_info_ptr->GetProcessInfo().GetName()))
Added real user/group id, effective user/group id, and parent process ID to the ProcessInfo. llvm-svn: 128023
2011-03-22 05:25:07 +08:00
{
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. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
process_info.GetExecutableFile().SetFile (process_name, false);
Added real user/group id, effective user/group id, and parent process ID to the ProcessInfo. llvm-svn: 128023
2011-03-22 05:25:07 +08:00
return true;
}
}
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. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
process_info.GetExecutableFile().Clear();
Added real user/group id, effective user/group id, and parent process ID to the ProcessInfo. llvm-svn: 128023
2011-03-22 05:25:07 +08:00
return false;
}
static bool
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
GetMacOSXProcessCPUType (ProcessInstanceInfo &process_info)
Added real user/group id, effective user/group id, and parent process ID to the ProcessInfo. llvm-svn: 128023
2011-03-22 05:25:07 +08:00
{
if (process_info.ProcessIDIsValid())
{
// Make a new mib to stay thread safe
int mib[CTL_MAXNAME]={0,};
size_t mib_len = CTL_MAXNAME;
if (::sysctlnametomib("sysctl.proc_cputype", mib, &mib_len))
return false;
mib[mib_len] = process_info.GetProcessID();
mib_len++;
Silence the static analyzer. llvm-svn: 137396
2011-08-12 08:21:20 +08:00
cpu_type_t cpu, sub = 0;
<rdar://problem/11374963> When attaching on ARM hosted debuggers we were incorrectly setting the triple to "arm-apple-ios". This was happening because in the post attach code, we would lookup the process info through the platform, and if successful, we would get the architecture of the process. This code uses sysctl() calls, but we can only get the CPU type, not the subtype, so we would get ARM for CPU type and nothing for the cpu subtype, so this would map to "arm-apple-ios". I fixed the code to get the cpu subtype from "hw.cpusubtype" which is what we really want for ARM, and not the architecture is already correct. "add-dsym" then works like a charm. I also improved the command output when the architecture changes to show the entire triple instead of just the arch name. llvm-svn: 163868
2012-09-14 10:41:36 +08:00
size_t len = sizeof(cpu);
if (::sysctl (mib, mib_len, &cpu, &len, 0, 0) == 0)
Added real user/group id, effective user/group id, and parent process ID to the ProcessInfo. llvm-svn: 128023
2011-03-22 05:25:07 +08:00
{
switch (cpu)
{
Fix some names in the wake of my Mach-O changes to LLVM. llvm-svn: 189317
2013-08-27 13:04:57 +08:00
case CPU_TYPE_I386: sub = CPU_SUBTYPE_I386_ALL; break;
case CPU_TYPE_X86_64: sub = CPU_SUBTYPE_X86_64_ALL; break;
case CPU_TYPE_ARM:
<rdar://problem/11374963> When attaching on ARM hosted debuggers we were incorrectly setting the triple to "arm-apple-ios". This was happening because in the post attach code, we would lookup the process info through the platform, and if successful, we would get the architecture of the process. This code uses sysctl() calls, but we can only get the CPU type, not the subtype, so we would get ARM for CPU type and nothing for the cpu subtype, so this would map to "arm-apple-ios". I fixed the code to get the cpu subtype from "hw.cpusubtype" which is what we really want for ARM, and not the architecture is already correct. "add-dsym" then works like a charm. I also improved the command output when the architecture changes to show the entire triple instead of just the arch name. llvm-svn: 163868
2012-09-14 10:41:36 +08:00
{
uint32_t cpusubtype = 0;
len = sizeof(cpusubtype);
if (::sysctlbyname("hw.cpusubtype", &cpusubtype, &len, NULL, 0) == 0)
sub = cpusubtype;
}
break;
default:
break;
Added real user/group id, effective user/group id, and parent process ID to the ProcessInfo. llvm-svn: 128023
2011-03-22 05:25:07 +08:00
}
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. llvm-svn: 128239
2011-03-25 05:19:54 +08:00
process_info.GetArchitecture ().SetArchitecture (eArchTypeMachO, cpu, sub);
Added real user/group id, effective user/group id, and parent process ID to the ProcessInfo. llvm-svn: 128023
2011-03-22 05:25:07 +08:00
return true;
}
}
process_info.GetArchitecture().Clear();
return false;
}
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
static bool
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
GetMacOSXProcessArgs (const ProcessInstanceInfoMatch *match_info_ptr,
ProcessInstanceInfo &process_info)
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
{
if (process_info.ProcessIDIsValid())
{
Remove a ton of implicit narrowing conversions for C++11 compatibility. llvm-svn: 151071
2012-02-22 02:37:14 +08:00
int proc_args_mib[3] = { CTL_KERN, KERN_PROCARGS2, (int)process_info.GetProcessID() };
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
char arg_data[8192];
size_t arg_data_size = sizeof(arg_data);
if (::sysctl (proc_args_mib, 3, arg_data, &arg_data_size , NULL, 0) == 0)
{
DataExtractor data (arg_data, arg_data_size, lldb::endian::InlHostByteOrder(), sizeof(void *));
<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. llvm-svn: 173463
2013-01-26 02:06:21 +08:00
lldb::offset_t offset = 0;
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
uint32_t argc = data.GetU32 (&offset);
const char *cstr;
cstr = data.GetCStr (&offset);
if (cstr)
{
process_info.GetExecutableFile().SetFile(cstr, false);
if (match_info_ptr == NULL ||
NameMatches (process_info.GetExecutableFile().GetFilename().GetCString(),
match_info_ptr->GetNameMatchType(),
match_info_ptr->GetProcessInfo().GetName()))
{
// Skip NULLs
while (1)
{
const uint8_t *p = data.PeekData(offset, 1);
if ((p == NULL) || (*p != '\0'))
break;
++offset;
}
// Now extract all arguments
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
Args &proc_args = process_info.GetArguments();
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
for (int i=0; i<argc; ++i)
{
cstr = data.GetCStr(&offset);
if (cstr)
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
proc_args.AppendArgument(cstr);
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
}
return true;
}
}
}
}
return false;
}
Added real user/group id, effective user/group id, and parent process ID to the ProcessInfo. llvm-svn: 128023
2011-03-22 05:25:07 +08:00
static bool
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
GetMacOSXProcessUserAndGroup (ProcessInstanceInfo &process_info)
Added real user/group id, effective user/group id, and parent process ID to the ProcessInfo. llvm-svn: 128023
2011-03-22 05:25:07 +08:00
{
if (process_info.ProcessIDIsValid())
{
int mib[4];
mib[0] = CTL_KERN;
mib[1] = KERN_PROC;
mib[2] = KERN_PROC_PID;
mib[3] = process_info.GetProcessID();
struct kinfo_proc proc_kinfo;
size_t proc_kinfo_size = sizeof(struct kinfo_proc);
if (::sysctl (mib, 4, &proc_kinfo, &proc_kinfo_size, NULL, 0) == 0)
{
if (proc_kinfo_size > 0)
{
process_info.SetParentProcessID (proc_kinfo.kp_eproc.e_ppid);
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
process_info.SetUserID (proc_kinfo.kp_eproc.e_pcred.p_ruid);
process_info.SetGroupID (proc_kinfo.kp_eproc.e_pcred.p_rgid);
Added real user/group id, effective user/group id, and parent process ID to the ProcessInfo. llvm-svn: 128023
2011-03-22 05:25:07 +08:00
process_info.SetEffectiveUserID (proc_kinfo.kp_eproc.e_ucred.cr_uid);
if (proc_kinfo.kp_eproc.e_ucred.cr_ngroups > 0)
process_info.SetEffectiveGroupID (proc_kinfo.kp_eproc.e_ucred.cr_groups[0]);
else
process_info.SetEffectiveGroupID (UINT32_MAX);
return true;
}
}
}
process_info.SetParentProcessID (LLDB_INVALID_PROCESS_ID);
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
process_info.SetUserID (UINT32_MAX);
process_info.SetGroupID (UINT32_MAX);
Added real user/group id, effective user/group id, and parent process ID to the ProcessInfo. llvm-svn: 128023
2011-03-22 05:25:07 +08:00
process_info.SetEffectiveUserID (UINT32_MAX);
process_info.SetEffectiveGroupID (UINT32_MAX);
return false;
}
uint32_t
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
Host::FindProcesses (const ProcessInstanceInfoMatch &match_info, ProcessInstanceInfoList &process_infos)
Added real user/group id, effective user/group id, and parent process ID to the ProcessInfo. llvm-svn: 128023
2011-03-22 05:25:07 +08:00
{
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
std::vector<struct kinfo_proc> kinfos;
Added real user/group id, effective user/group id, and parent process ID to the ProcessInfo. llvm-svn: 128023
2011-03-22 05:25:07 +08:00
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
int mib[3] = { CTL_KERN, KERN_PROC, KERN_PROC_ALL };
Added real user/group id, effective user/group id, and parent process ID to the ProcessInfo. llvm-svn: 128023
2011-03-22 05:25:07 +08:00
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
size_t pid_data_size = 0;
if (::sysctl (mib, 4, NULL, &pid_data_size, NULL, 0) != 0)
Added real user/group id, effective user/group id, and parent process ID to the ProcessInfo. llvm-svn: 128023
2011-03-22 05:25:07 +08:00
return 0;
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
// Add a few extra in case a few more show up
const size_t estimated_pid_count = (pid_data_size / sizeof(struct kinfo_proc)) + 10;
kinfos.resize (estimated_pid_count);
pid_data_size = kinfos.size() * sizeof(struct kinfo_proc);
if (::sysctl (mib, 4, &kinfos[0], &pid_data_size, NULL, 0) != 0)
return 0;
const size_t actual_pid_count = (pid_data_size / sizeof(struct kinfo_proc));
bool all_users = match_info.GetMatchAllUsers();
const lldb::pid_t our_pid = getpid();
const uid_t our_uid = getuid();
for (int i = 0; i < actual_pid_count; i++)
Added real user/group id, effective user/group id, and parent process ID to the ProcessInfo. llvm-svn: 128023
2011-03-22 05:25:07 +08:00
{
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
const struct kinfo_proc &kinfo = kinfos[i];
Added real user/group id, effective user/group id, and parent process ID to the ProcessInfo. llvm-svn: 128023
2011-03-22 05:25:07 +08:00
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
bool kinfo_user_matches = false;
if (all_users)
kinfo_user_matches = true;
else
kinfo_user_matches = kinfo.kp_eproc.e_pcred.p_ruid == our_uid;
Change the macosx Host::FindProcesses() to include all processes (running under any uid) if lldb is being run as root. It might be better to handle this up at the ProcessInstanceInfoMatch class with its m_match_all_users ivar instead of down here... llvm-svn: 139566
2011-09-13 08:52:59 +08:00
// Special case, if lldb is being run as root we can attach to anything.
if (our_uid == 0)
kinfo_user_matches = true;
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
if (kinfo_user_matches == false || // Make sure the user is acceptable
kinfo.kp_proc.p_pid == our_pid || // Skip this process
kinfo.kp_proc.p_pid == 0 || // Skip kernel (kernel pid is zero)
kinfo.kp_proc.p_stat == SZOMB || // Zombies are bad, they like brains...
kinfo.kp_proc.p_flag & P_TRACED || // Being debugged?
kinfo.kp_proc.p_flag & P_WEXIT || // Working on exiting?
kinfo.kp_proc.p_flag & P_TRANSLATED) // Skip translated ppc (Rosetta)
continue;
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
ProcessInstanceInfo process_info;
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
process_info.SetProcessID (kinfo.kp_proc.p_pid);
process_info.SetParentProcessID (kinfo.kp_eproc.e_ppid);
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
process_info.SetUserID (kinfo.kp_eproc.e_pcred.p_ruid);
process_info.SetGroupID (kinfo.kp_eproc.e_pcred.p_rgid);
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
process_info.SetEffectiveUserID (kinfo.kp_eproc.e_ucred.cr_uid);
if (kinfo.kp_eproc.e_ucred.cr_ngroups > 0)
process_info.SetEffectiveGroupID (kinfo.kp_eproc.e_ucred.cr_groups[0]);
else
process_info.SetEffectiveGroupID (UINT32_MAX);
// Make sure our info matches before we go fetch the name and cpu type
if (match_info.Matches (process_info))
Added real user/group id, effective user/group id, and parent process ID to the ProcessInfo. llvm-svn: 128023
2011-03-22 05:25:07 +08:00
{
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
if (GetMacOSXProcessArgs (&match_info, process_info))
{
GetMacOSXProcessCPUType (process_info);
if (match_info.Matches (process_info))
process_infos.Append (process_info);
}
Added real user/group id, effective user/group id, and parent process ID to the ProcessInfo. llvm-svn: 128023
2011-03-22 05:25:07 +08:00
}
}
return process_infos.GetSize();
}
bool
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
Host::GetProcessInfo (lldb::pid_t pid, ProcessInstanceInfo &process_info)
Added real user/group id, effective user/group id, and parent process ID to the ProcessInfo. llvm-svn: 128023
2011-03-22 05:25:07 +08:00
{
process_info.SetProcessID(pid);
<rdar://10950196> Returns true when there is any info retrieved. llvm-svn: 151678
2012-02-29 08:09:16 +08:00
bool success = false;
Added the ability to get a broadcaster event name for a given broadcaster event. Modified the ProcessInfo structure to contain all process arguments. Using the new function calls on MacOSX allows us to see the full process name, not just the first 16 characters. Added a new platform command: "platform process info <pid> [<pid> <pid> ...]" that can be used to get detailed information for a process including all arguments, user and group info and more. llvm-svn: 128694
2011-04-01 08:29:43 +08:00
if (GetMacOSXProcessArgs (NULL, process_info))
<rdar://10950196> Returns true when there is any info retrieved. llvm-svn: 151678
2012-02-29 08:09:16 +08:00
success = true;
if (GetMacOSXProcessCPUType (process_info))
success = true;
if (GetMacOSXProcessUserAndGroup (process_info))
success = true;
if (success)
Added real user/group id, effective user/group id, and parent process ID to the ProcessInfo. llvm-svn: 128023
2011-03-22 05:25:07 +08:00
return true;
<rdar://10950196> Returns true when there is any info retrieved. llvm-svn: 151678
2012-02-29 08:09:16 +08:00
Added real user/group id, effective user/group id, and parent process ID to the ProcessInfo. llvm-svn: 128023
2011-03-22 05:25:07 +08:00
process_info.Clear();
return false;
}
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
static short
GetPosixspawnFlags (ProcessLaunchInfo &launch_info)
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
{
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
short flags = POSIX_SPAWN_SETSIGDEF | POSIX_SPAWN_SETSIGMASK;
if (launch_info.GetFlags().Test (eLaunchFlagExec))
flags |= POSIX_SPAWN_SETEXEC; // Darwin specific posix_spawn flag
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
if (launch_info.GetFlags().Test (eLaunchFlagDebug))
flags |= POSIX_SPAWN_START_SUSPENDED; // Darwin specific posix_spawn flag
if (launch_info.GetFlags().Test (eLaunchFlagDisableASLR))
flags |= _POSIX_SPAWN_DISABLE_ASLR; // Darwin specific posix_spawn flag
When the Platform launches a process for debugging, make sure it goes into a separate process group, otherwise ^C will both cause us to try to Stop it manually, AND send it a SIGINT, which can confuse us. rdar://problem/11369230 llvm-svn: 157791
2012-06-01 09:22:13 +08:00
if (launch_info.GetLaunchInSeparateProcessGroup())
flags |= POSIX_SPAWN_SETPGROUP;
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
<rdar://problem/10942472> Allows the debugger to put a more sensible prompt when debugging as root. llvm-svn: 151605
2012-02-28 09:18:30 +08:00
//#ifdef POSIX_SPAWN_CLOEXEC_DEFAULT
// // Close all files exception those with file actions if this is supported.
// flags |= POSIX_SPAWN_CLOEXEC_DEFAULT;
//#endif
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
return flags;
}
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
Use a new define, NO_XPC_SERVICES, to indicate that macosx/Host.mm shouldn't compile any of the XPC support code. Update macosx/Host.mm to use that define. Add a LLDB_DISABLE_PYTHON ifdef block around a new function in Core/FormatManager.cpp. <rdar://problem/10942125> llvm-svn: 152293
2012-03-08 12:03:25 +08:00
#if !NO_XPC_SERVICES
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
static void
PackageXPCArguments (xpc_object_t message, const char *prefix, const Args& args)
{
size_t count = args.GetArgumentCount();
char buf[50]; // long enough for 'argXXX'
memset(buf, 0, 50);
sprintf(buf, "%sCount", prefix);
xpc_dictionary_set_int64(message, buf, count);
for (int i=0; i<count; i++) {
memset(buf, 0, 50);
sprintf(buf, "%s%i", prefix, i);
xpc_dictionary_set_string(message, buf, args.GetArgumentAtIndex(i));
}
}
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
<rdar://problem/11408853> We make sure that if the user cancels out of the authentication dialog to add 'com.apple.lldb.LaunchUsingXPC' rights to /etc/authorization, we don't try to do AuthorizationCopyRights. As well, refactored a bit so that control flow is easier to read for other folks. Added more comments. llvm-svn: 156423
2012-05-09 05:32:32 +08:00
/*
A valid authorizationRef means that
- there is the LaunchUsingXPCRightName rights in the /etc/authorization
- we have successfully copied the rights to be send over the XPC wire
Once obtained, it will be valid for as long as the process lives.
*/
<rdar://problem/10942472> Allows the debugger to put a more sensible prompt when debugging as root. llvm-svn: 151605
2012-02-28 09:18:30 +08:00
static AuthorizationRef authorizationRef = NULL;
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
static Error
getXPCAuthorization (ProcessLaunchInfo &launch_info)
{
Error error;
<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. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_HOST | LIBLLDB_LOG_PROCESS));
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
<rdar://problem/11408853> We make sure that if the user cancels out of the authentication dialog to add 'com.apple.lldb.LaunchUsingXPC' rights to /etc/authorization, we don't try to do AuthorizationCopyRights. As well, refactored a bit so that control flow is easier to read for other folks. Added more comments. llvm-svn: 156423
2012-05-09 05:32:32 +08:00
if ((launch_info.GetUserID() == 0) && !authorizationRef)
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
{
<rdar://problem/11408853> We make sure that if the user cancels out of the authentication dialog to add 'com.apple.lldb.LaunchUsingXPC' rights to /etc/authorization, we don't try to do AuthorizationCopyRights. As well, refactored a bit so that control flow is easier to read for other folks. Added more comments. llvm-svn: 156423
2012-05-09 05:32:32 +08:00
OSStatus createStatus = AuthorizationCreate(NULL, kAuthorizationEmptyEnvironment, kAuthorizationFlagDefaults, &authorizationRef);
if (createStatus != errAuthorizationSuccess)
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
{
<rdar://problem/11408853> We make sure that if the user cancels out of the authentication dialog to add 'com.apple.lldb.LaunchUsingXPC' rights to /etc/authorization, we don't try to do AuthorizationCopyRights. As well, refactored a bit so that control flow is easier to read for other folks. Added more comments. llvm-svn: 156423
2012-05-09 05:32:32 +08:00
error.SetError(1, eErrorTypeGeneric);
error.SetErrorString("Can't create authorizationRef.");
if (log)
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
{
<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. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
error.PutToLog(log, "%s", error.AsCString());
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
}
<rdar://problem/11408853> We make sure that if the user cancels out of the authentication dialog to add 'com.apple.lldb.LaunchUsingXPC' rights to /etc/authorization, we don't try to do AuthorizationCopyRights. As well, refactored a bit so that control flow is easier to read for other folks. Added more comments. llvm-svn: 156423
2012-05-09 05:32:32 +08:00
return error;
}
OSStatus rightsStatus = AuthorizationRightGet(LaunchUsingXPCRightName, NULL);
if (rightsStatus != errAuthorizationSuccess)
{
// No rights in the security database, Create it with the right prompt.
CFStringRef prompt = CFSTR("Xcode is trying to take control of a root process.");
CFStringRef keys[] = { CFSTR("en") };
CFTypeRef values[] = { prompt };
CFDictionaryRef promptDict = CFDictionaryCreate(kCFAllocatorDefault, (const void **)keys, (const void **)values, 1, &kCFCopyStringDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks);
<rdar://11033946> Made sure that the root XPC service validate the right before starting the service. The right is created and authenticated by clients (in this case, lldb) and transferred over for validiation. llvm-svn: 152802
2012-03-15 23:37:50 +08:00
<rdar://problem/11408853> We make sure that if the user cancels out of the authentication dialog to add 'com.apple.lldb.LaunchUsingXPC' rights to /etc/authorization, we don't try to do AuthorizationCopyRights. As well, refactored a bit so that control flow is easier to read for other folks. Added more comments. llvm-svn: 156423
2012-05-09 05:32:32 +08:00
CFStringRef keys1[] = { CFSTR("class"), CFSTR("group"), CFSTR("comment"), CFSTR("default-prompt"), CFSTR("shared") };
CFTypeRef values1[] = { CFSTR("user"), CFSTR("admin"), CFSTR(LaunchUsingXPCRightName), promptDict, kCFBooleanFalse };
CFDictionaryRef dict = CFDictionaryCreate(kCFAllocatorDefault, (const void **)keys1, (const void **)values1, 5, &kCFCopyStringDictionaryKeyCallBacks, &kCFTypeDictionaryValueCallBacks);
rightsStatus = AuthorizationRightSet(authorizationRef, LaunchUsingXPCRightName, dict, NULL, NULL, NULL);
CFRelease(promptDict);
CFRelease(dict);
}
OSStatus copyRightStatus = errAuthorizationDenied;
if (rightsStatus == errAuthorizationSuccess)
{
AuthorizationItem item1 = { LaunchUsingXPCRightName, 0, NULL, 0 };
AuthorizationItem items[] = {item1};
AuthorizationRights requestedRights = {1, items };
AuthorizationFlags authorizationFlags = kAuthorizationFlagInteractionAllowed | kAuthorizationFlagExtendRights;
copyRightStatus = AuthorizationCopyRights(authorizationRef, &requestedRights, kAuthorizationEmptyEnvironment, authorizationFlags, NULL);
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
}
<rdar://problem/11408853> We make sure that if the user cancels out of the authentication dialog to add 'com.apple.lldb.LaunchUsingXPC' rights to /etc/authorization, we don't try to do AuthorizationCopyRights. As well, refactored a bit so that control flow is easier to read for other folks. Added more comments. llvm-svn: 156423
2012-05-09 05:32:32 +08:00
if (copyRightStatus != errAuthorizationSuccess)
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
{
// Eventually when the commandline supports running as root and the user is not
// logged in in the current audit session, we will need the trick in gdb where
// we ask the user to type in the root passwd in the terminal.
error.SetError(2, eErrorTypeGeneric);
<rdar://11033946> Made sure that the root XPC service validate the right before starting the service. The right is created and authenticated by clients (in this case, lldb) and transferred over for validiation. llvm-svn: 152802
2012-03-15 23:37:50 +08:00
error.SetErrorStringWithFormat("Launching as root needs root authorization.");
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
if (log)
{
<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. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
error.PutToLog(log, "%s", error.AsCString());
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
}
<rdar://problem/11408853> We make sure that if the user cancels out of the authentication dialog to add 'com.apple.lldb.LaunchUsingXPC' rights to /etc/authorization, we don't try to do AuthorizationCopyRights. As well, refactored a bit so that control flow is easier to read for other folks. Added more comments. llvm-svn: 156423
2012-05-09 05:32:32 +08:00
if (authorizationRef)
{
AuthorizationFree(authorizationRef, kAuthorizationFlagDefaults);
authorizationRef = NULL;
}
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
}
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
}
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
return error;
}
#endif
static Error
LaunchProcessXPC (const char *exe_path, ProcessLaunchInfo &launch_info, ::pid_t &pid)
{
Use a new define, NO_XPC_SERVICES, to indicate that macosx/Host.mm shouldn't compile any of the XPC support code. Update macosx/Host.mm to use that define. Add a LLDB_DISABLE_PYTHON ifdef block around a new function in Core/FormatManager.cpp. <rdar://problem/10942125> llvm-svn: 152293
2012-03-08 12:03:25 +08:00
#if !NO_XPC_SERVICES
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
Error error = getXPCAuthorization(launch_info);
if (error.Fail())
return error;
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
<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. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_HOST | LIBLLDB_LOG_PROCESS));
<rdar://problem/12850287> When there is XPC connection error, we will report it now. llvm-svn: 169787
2012-12-11 07:02:33 +08:00
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
uid_t requested_uid = launch_info.GetUserID();
const char *xpc_service = nil;
<rdar://11033946> Made sure that the root XPC service validate the right before starting the service. The right is created and authenticated by clients (in this case, lldb) and transferred over for validiation. llvm-svn: 152802
2012-03-15 23:37:50 +08:00
bool send_auth = false;
AuthorizationExternalForm extForm;
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
if ((requested_uid == UINT32_MAX) || (requested_uid == Host::GetEffectiveUserID()))
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
{
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
xpc_service = "com.apple.lldb.launcherXPCService";
}
else if (requested_uid == 0)
{
<rdar://11033946> Made sure that the root XPC service validate the right before starting the service. The right is created and authenticated by clients (in this case, lldb) and transferred over for validiation. llvm-svn: 152802
2012-03-15 23:37:50 +08:00
if (AuthorizationMakeExternalForm(authorizationRef, &extForm) == errAuthorizationSuccess)
{
send_auth = true;
}
else
{
<rdar://problem/12850287> When there is XPC connection error, we will report it now. llvm-svn: 169787
2012-12-11 07:02:33 +08:00
error.SetError(3, eErrorTypeGeneric);
<rdar://11033946> Made sure that the root XPC service validate the right before starting the service. The right is created and authenticated by clients (in this case, lldb) and transferred over for validiation. llvm-svn: 152802
2012-03-15 23:37:50 +08:00
error.SetErrorStringWithFormat("Launching root via XPC needs to externalize authorization reference.");
if (log)
{
<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. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
error.PutToLog(log, "%s", error.AsCString());
<rdar://11033946> Made sure that the root XPC service validate the right before starting the service. The right is created and authenticated by clients (in this case, lldb) and transferred over for validiation. llvm-svn: 152802
2012-03-15 23:37:50 +08:00
}
return error;
}
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
xpc_service = "com.apple.lldb.launcherRootXPCService";
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
}
else
{
<rdar://problem/12850287> When there is XPC connection error, we will report it now. llvm-svn: 169787
2012-12-11 07:02:33 +08:00
error.SetError(4, eErrorTypeGeneric);
<rdar://11033946> Made sure that the root XPC service validate the right before starting the service. The right is created and authenticated by clients (in this case, lldb) and transferred over for validiation. llvm-svn: 152802
2012-03-15 23:37:50 +08:00
error.SetErrorStringWithFormat("Launching via XPC is only currently available for either the login user or root.");
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
if (log)
{
<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. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
error.PutToLog(log, "%s", error.AsCString());
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
}
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
return error;
}
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
xpc_connection_t conn = xpc_connection_create(xpc_service, NULL);
xpc_connection_set_event_handler(conn, ^(xpc_object_t event) {
xpc_type_t type = xpc_get_type(event);
if (type == XPC_TYPE_ERROR) {
if (event == XPC_ERROR_CONNECTION_INTERRUPTED) {
<rdar://problem/12850287> When there is XPC connection error, we will report it now. llvm-svn: 169787
2012-12-11 07:02:33 +08:00
// The service has either canceled itself, crashed, or been terminated.
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
// The XPC connection is still valid and sending a message to it will re-launch the service.
// If the service is state-full, this is the time to initialize the new service.
return;
} else if (event == XPC_ERROR_CONNECTION_INVALID) {
// The service is invalid. Either the service name supplied to xpc_connection_create() is incorrect
// or we (this process) have canceled the service; we can do any cleanup of appliation state at this point.
// printf("Service disconnected");
return;
} else {
// printf("Unexpected error from service: %s", xpc_dictionary_get_string(event, XPC_ERROR_KEY_DESCRIPTION));
}
<rdar://problem/12850287> When there is XPC connection error, we will report it now. llvm-svn: 169787
2012-12-11 07:02:33 +08:00
} else {
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
// printf("Received unexpected event in handler");
}
});
<rdar://problem/12850287> When there is XPC connection error, we will report it now. llvm-svn: 169787
2012-12-11 07:02:33 +08:00
xpc_connection_set_finalizer_f (conn, xpc_finalizer_t(xpc_release));
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
xpc_connection_resume (conn);
xpc_object_t message = xpc_dictionary_create (nil, nil, 0);
<rdar://11033946> Made sure that the root XPC service validate the right before starting the service. The right is created and authenticated by clients (in this case, lldb) and transferred over for validiation. llvm-svn: 152802
2012-03-15 23:37:50 +08:00
if (send_auth)
{
xpc_dictionary_set_data(message, LauncherXPCServiceAuthKey, extForm.bytes, sizeof(AuthorizationExternalForm));
}
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
PackageXPCArguments(message, LauncherXPCServiceArgPrefxKey, launch_info.GetArguments());
PackageXPCArguments(message, LauncherXPCServiceEnvPrefxKey, launch_info.GetEnvironmentEntries());
// Posix spawn stuff.
xpc_dictionary_set_int64(message, LauncherXPCServiceCPUTypeKey, launch_info.GetArchitecture().GetMachOCPUType());
xpc_dictionary_set_int64(message, LauncherXPCServicePosixspawnFlagsKey, GetPosixspawnFlags(launch_info));
xpc_object_t reply = xpc_connection_send_message_with_reply_sync(conn, message);
<rdar://problem/12850287> When there is XPC connection error, we will report it now. llvm-svn: 169787
2012-12-11 07:02:33 +08:00
xpc_type_t returnType = xpc_get_type(reply);
if (returnType == XPC_TYPE_DICTIONARY)
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
{
<rdar://problem/12850287> When there is XPC connection error, we will report it now. llvm-svn: 169787
2012-12-11 07:02:33 +08:00
pid = xpc_dictionary_get_int64(reply, LauncherXPCServiceChildPIDKey);
if (pid == 0)
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
{
<rdar://problem/12850287> When there is XPC connection error, we will report it now. llvm-svn: 169787
2012-12-11 07:02:33 +08:00
int errorType = xpc_dictionary_get_int64(reply, LauncherXPCServiceErrorTypeKey);
int errorCode = xpc_dictionary_get_int64(reply, LauncherXPCServiceCodeTypeKey);
error.SetError(errorCode, eErrorTypeGeneric);
error.SetErrorStringWithFormat("Problems with launching via XPC. Error type : %i, code : %i", errorType, errorCode);
if (log)
{
<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. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
error.PutToLog(log, "%s", error.AsCString());
<rdar://problem/12850287> When there is XPC connection error, we will report it now. llvm-svn: 169787
2012-12-11 07:02:33 +08:00
}
if (authorizationRef)
{
AuthorizationFree(authorizationRef, kAuthorizationFlagDefaults);
authorizationRef = NULL;
}
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
}
<rdar://problem/12850287> When there is XPC connection error, we will report it now. llvm-svn: 169787
2012-12-11 07:02:33 +08:00
}
else if (returnType == XPC_TYPE_ERROR)
{
error.SetError(5, eErrorTypeGeneric);
error.SetErrorStringWithFormat("Problems with launching via XPC. XPC error : %s", xpc_dictionary_get_string(reply, XPC_ERROR_KEY_DESCRIPTION));
if (log)
<rdar://problem/11408853> We make sure that if the user cancels out of the authentication dialog to add 'com.apple.lldb.LaunchUsingXPC' rights to /etc/authorization, we don't try to do AuthorizationCopyRights. As well, refactored a bit so that control flow is easier to read for other folks. Added more comments. llvm-svn: 156423
2012-05-09 05:32:32 +08:00
{
<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. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
error.PutToLog(log, "%s", error.AsCString());
<rdar://problem/11408853> We make sure that if the user cancels out of the authentication dialog to add 'com.apple.lldb.LaunchUsingXPC' rights to /etc/authorization, we don't try to do AuthorizationCopyRights. As well, refactored a bit so that control flow is easier to read for other folks. Added more comments. llvm-svn: 156423
2012-05-09 05:32:32 +08:00
}
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
}
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
Unify how we get host version on Mac OS X & iOS. Also remove our dependency on UIKit & AppKit. Cleaned up the project files a bit. <rdar://problem/11814498> llvm-svn: 160147
2012-07-13 07:16:43 +08:00
return error;
#else
Error error;
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
return error;
Use a new define, NO_XPC_SERVICES, to indicate that macosx/Host.mm shouldn't compile any of the XPC support code. Update macosx/Host.mm to use that define. Add a LLDB_DISABLE_PYTHON ifdef block around a new function in Core/FormatManager.cpp. <rdar://problem/10942125> llvm-svn: 152293
2012-03-08 12:03:25 +08:00
#endif
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
}
static Error
LaunchProcessPosixSpawn (const char *exe_path, ProcessLaunchInfo &launch_info, ::pid_t &pid)
{
Error error;
<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. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAllCategoriesSet (LIBLLDB_LOG_HOST | LIBLLDB_LOG_PROCESS));
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
posix_spawnattr_t attr;
error.SetError( ::posix_spawnattr_init (&attr), eErrorTypePOSIX);
if (error.Fail() || log)
<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. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
error.PutToLog(log, "::posix_spawnattr_init ( &attr )");
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
if (error.Fail())
return error;
// Make a quick class that will cleanup the posix spawn attributes in case
// we return in the middle of this function.
lldb_utility::CleanUp <posix_spawnattr_t *, int> posix_spawnattr_cleanup(&attr, posix_spawnattr_destroy);
Python does some bad things to the signal masks in the current process and then we spawn child processes (debugserver, etc) and those bad settings get inherited. We stop this from happening by correctly mucking with the posix spawn attributes. llvm-svn: 143176
2011-10-28 09:24:12 +08:00
sigset_t no_signals;
sigset_t all_signals;
sigemptyset (&no_signals);
sigfillset (&all_signals);
::posix_spawnattr_setsigmask(&attr, &no_signals);
::posix_spawnattr_setsigdefault(&attr, &all_signals);
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
short flags = GetPosixspawnFlags(launch_info);
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
error.SetError( ::posix_spawnattr_setflags (&attr, flags), eErrorTypePOSIX);
if (error.Fail() || log)
<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. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
error.PutToLog(log, "::posix_spawnattr_setflags ( &attr, flags=0x%8.8x )", flags);
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
if (error.Fail())
return error;
#if !defined(__arm__)
// We don't need to do this for ARM, and we really shouldn't now that we
// have multiple CPU subtypes and no posix_spawnattr call that allows us
// to set which CPU subtype to launch...
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
const ArchSpec &arch_spec = launch_info.GetArchitecture();
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
cpu_type_t cpu = arch_spec.GetMachOCPUType();
if (cpu != 0 &&
cpu != UINT32_MAX &&
cpu != LLDB_INVALID_CPUTYPE)
{
size_t ocount = 0;
error.SetError( ::posix_spawnattr_setbinpref_np (&attr, 1, &cpu, &ocount), eErrorTypePOSIX);
if (error.Fail() || log)
<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. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
error.PutToLog(log, "::posix_spawnattr_setbinpref_np ( &attr, 1, cpu_type = 0x%8.8x, count => %llu )", cpu, (uint64_t)ocount);
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
if (error.Fail() || ocount != 1)
return error;
}
#endif
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
const char *tmp_argv[2];
char * const *argv = (char * const*)launch_info.GetArguments().GetConstArgumentVector();
char * const *envp = (char * const*)launch_info.GetEnvironmentEntries().GetConstArgumentVector();
if (argv == NULL)
{
// posix_spawn gets very unhappy if it doesn't have at least the program
// name in argv[0]. One of the side affects I have noticed is the environment
// variables don't make it into the child process if "argv == NULL"!!!
tmp_argv[0] = exe_path;
tmp_argv[1] = NULL;
argv = (char * const*)tmp_argv;
}
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. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
const char *working_dir = launch_info.GetWorkingDirectory();
if (working_dir)
{
// No more thread specific current working directory
Provide more information when process launch can't change directory to the path passed with -w Test this functionality. llvm-svn: 160130
2012-07-12 22:09:25 +08:00
if (__pthread_chdir (working_dir) < 0) {
if (errno == ENOENT) {
error.SetErrorStringWithFormat("No such file or directory: %s", working_dir);
} else if (errno == ENOTDIR) {
error.SetErrorStringWithFormat("Path doesn't name a directory: %s", working_dir);
} else {
error.SetErrorStringWithFormat("An unknown error occurred when changing directory for process execution.");
}
return error;
}
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. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
}
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
const size_t num_file_actions = launch_info.GetNumFileActions ();
if (num_file_actions > 0)
{
posix_spawn_file_actions_t file_actions;
error.SetError( ::posix_spawn_file_actions_init (&file_actions), eErrorTypePOSIX);
if (error.Fail() || log)
<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. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
error.PutToLog(log, "::posix_spawn_file_actions_init ( &file_actions )");
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
if (error.Fail())
return error;
// Make a quick class that will cleanup the posix spawn attributes in case
// we return in the middle of this function.
lldb_utility::CleanUp <posix_spawn_file_actions_t *, int> posix_spawn_file_actions_cleanup (&file_actions, posix_spawn_file_actions_destroy);
for (size_t i=0; i<num_file_actions; ++i)
{
const ProcessLaunchInfo::FileAction *launch_file_action = launch_info.GetFileActionAtIndex(i);
if (launch_file_action)
{
if (!ProcessLaunchInfo::FileAction::AddPosixSpawnFileAction (&file_actions,
launch_file_action,
<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. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
log,
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
error))
return error;
}
}
error.SetError (::posix_spawnp (&pid,
exe_path,
&file_actions,
&attr,
argv,
envp),
eErrorTypePOSIX);
if (error.Fail() || log)
Added the ability to download a symboled executable and symbol file given a UUID. llvm-svn: 164753
2012-09-27 11:13:55 +08:00
{
<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. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
error.PutToLog(log, "::posix_spawnp ( pid => %i, path = '%s', file_actions = %p, attr = %p, argv = %p, envp = %p )",
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
pid,
exe_path,
&file_actions,
&attr,
argv,
envp);
Added the ability to download a symboled executable and symbol file given a UUID. llvm-svn: 164753
2012-09-27 11:13:55 +08:00
if (log)
{
for (int ii=0; argv[ii]; ++ii)
log->Printf("argv[%i] = '%s'", ii, argv[ii]);
}
}
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
}
else
{
error.SetError (::posix_spawnp (&pid,
exe_path,
NULL,
&attr,
argv,
envp),
eErrorTypePOSIX);
if (error.Fail() || log)
Added the ability to download a symboled executable and symbol file given a UUID. llvm-svn: 164753
2012-09-27 11:13:55 +08:00
{
<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. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
error.PutToLog(log, "::posix_spawnp ( pid => %i, path = '%s', file_actions = NULL, attr = %p, argv = %p, envp = %p )",
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
pid,
exe_path,
&attr,
argv,
envp);
Added the ability to download a symboled executable and symbol file given a UUID. llvm-svn: 164753
2012-09-27 11:13:55 +08:00
if (log)
{
for (int ii=0; argv[ii]; ++ii)
log->Printf("argv[%i] = '%s'", ii, argv[ii]);
}
}
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
}
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. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
if (working_dir)
{
// No more thread specific current working directory
__pthread_fchdir (-1);
}
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
return error;
}
static bool
ShouldLaunchUsingXPC(const char *exe_path, ProcessLaunchInfo &launch_info)
{
bool result = false;
Use a new define, NO_XPC_SERVICES, to indicate that macosx/Host.mm shouldn't compile any of the XPC support code. Update macosx/Host.mm to use that define. Add a LLDB_DISABLE_PYTHON ifdef block around a new function in Core/FormatManager.cpp. <rdar://problem/10942125> llvm-svn: 152293
2012-03-08 12:03:25 +08:00
#if !NO_XPC_SERVICES
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
const char *debugserver = "/debugserver";
int len = strlen(debugserver);
int exe_len = strlen(exe_path);
if (exe_len >= len)
{
const char *part = exe_path + (exe_len - len);
if (strcmp(part, debugserver) == 0)
{
// We are dealing with debugserver.
uid_t requested_uid = launch_info.GetUserID();
if (requested_uid == 0)
{
// Launching XPC works for root. It also works for the non-attaching case for current login
// but unfortunately, we can't detect it here.
result = true;
}
}
}
#endif
return result;
}
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. llvm-svn: 144615
2011-11-15 11:53:30 +08:00
<rdar://problem/3535148> Added ability to debug root processes on OS X. This uses XPC service that is available on Lion and above only. llvm-svn: 151419
2012-02-25 09:07:38 +08:00
Error
Host::LaunchProcess (ProcessLaunchInfo &launch_info)
{
Error error;
char exe_path[PATH_MAX];
PlatformSP host_platform_sp (Platform::GetDefaultPlatform ());
const ArchSpec &arch_spec = launch_info.GetArchitecture();
FileSpec exe_spec(launch_info.GetExecutableFile());
FileSpec::FileType file_type = exe_spec.GetFileType();
if (file_type != FileSpec::eFileTypeRegular)
{
lldb::ModuleSP exe_module_sp;
error = host_platform_sp->ResolveExecutable (exe_spec,
arch_spec,
exe_module_sp,
NULL);
if (error.Fail())
return error;
if (exe_module_sp)
exe_spec = exe_module_sp->GetFileSpec();
}
if (exe_spec.Exists())
{
exe_spec.GetPath (exe_path, sizeof(exe_path));
}
else
{
launch_info.GetExecutableFile().GetPath (exe_path, sizeof(exe_path));
error.SetErrorStringWithFormat ("executable doesn't exist: '%s'", exe_path);
return error;
}
if (launch_info.GetFlags().Test (eLaunchFlagLaunchInTTY))
{
#if !defined(__arm__)
return LaunchInNewTerminalWithAppleScript (exe_path, launch_info);
#else
error.SetErrorString ("launching a processs in a new terminal is not supported on iOS devices");
return error;
#endif
}
::pid_t pid = LLDB_INVALID_PROCESS_ID;
if (ShouldLaunchUsingXPC(exe_path, launch_info))
{
error = LaunchProcessXPC(exe_path, launch_info, pid);
}
else
{
error = LaunchProcessPosixSpawn(exe_path, launch_info, pid);
}
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
if (pid != LLDB_INVALID_PROCESS_ID)
{
// If all went well, then set the process ID into the launch info
Made the darwin host layer properly reap any child processes that it spawns. After recent changes we weren't reaping child processes resulting in many zombie processes. This was fixed by adding more settings to the ProcessLaunchOptions class that allow clients to specify a callback function and baton to be notified when their process dies. If one is not supplied a default callback will be used that "does the right thing". Cleaned up a race condition in the ProcessGDBRemote class that would attempt to monitor when debugserver died. Added an extra boolean to the process monitor callbacks that indicate if a process exited or not. If your process exited with a zero exit status and no signal, both items could be zero. Modified the process monitor functions to not require a callback function in order to reap the child process. llvm-svn: 144780
2011-11-16 13:37:56 +08:00
launch_info.SetProcessID(pid);
// Make sure we reap any processes we spawn or we will have zombies.
if (!launch_info.MonitorProcess())
{
const bool monitor_signals = false;
StartMonitoringChildProcess (Process::SetProcessExitStatus,
NULL,
pid,
monitor_signals);
}
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
}
else
{
// Invalid process ID, something didn't go well
if (error.Success())
error.SetErrorString ("process launch failed for unknown reasons");
}
return error;
}
Made the darwin host layer properly reap any child processes that it spawns. After recent changes we weren't reaping child processes resulting in many zombie processes. This was fixed by adding more settings to the ProcessLaunchOptions class that allow clients to specify a callback function and baton to be notified when their process dies. If one is not supplied a default callback will be used that "does the right thing". Cleaned up a race condition in the ProcessGDBRemote class that would attempt to monitor when debugserver died. Added an extra boolean to the process monitor callbacks that indicate if a process exited or not. If your process exited with a zero exit status and no signal, both items could be zero. Modified the process monitor functions to not require a callback function in order to reap the child process. llvm-svn: 144780
2011-11-16 13:37:56 +08:00
lldb::thread_t
Host::StartMonitoringChildProcess (Host::MonitorChildProcessCallback callback,
void *callback_baton,
lldb::pid_t pid,
bool monitor_signals)
{
lldb::thread_t thread = LLDB_INVALID_HOST_THREAD;
unsigned long mask = DISPATCH_PROC_EXIT;
if (monitor_signals)
mask |= DISPATCH_PROC_SIGNAL;
<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. llvm-svn: 178191
2013-03-28 07:08:40 +08:00
Log *log(lldb_private::GetLogIfAnyCategoriesSet (LIBLLDB_LOG_HOST | LIBLLDB_LOG_PROCESS));
Now that I fixed the uninitialized callback problem, I can enable GCD pid monitoring on darwin in the host layer. llvm-svn: 144918
2011-11-18 03:41:57 +08:00
Made the darwin host layer properly reap any child processes that it spawns. After recent changes we weren't reaping child processes resulting in many zombie processes. This was fixed by adding more settings to the ProcessLaunchOptions class that allow clients to specify a callback function and baton to be notified when their process dies. If one is not supplied a default callback will be used that "does the right thing". Cleaned up a race condition in the ProcessGDBRemote class that would attempt to monitor when debugserver died. Added an extra boolean to the process monitor callbacks that indicate if a process exited or not. If your process exited with a zero exit status and no signal, both items could be zero. Modified the process monitor functions to not require a callback function in order to reap the child process. llvm-svn: 144780
2011-11-16 13:37:56 +08:00
dispatch_source_t source = ::dispatch_source_create (DISPATCH_SOURCE_TYPE_PROC,
pid,
mask,
::dispatch_get_global_queue (DISPATCH_QUEUE_PRIORITY_DEFAULT,0));
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. llvm-svn: 129351
2011-04-12 13:54:46 +08:00
Now that I fixed the uninitialized callback problem, I can enable GCD pid monitoring on darwin in the host layer. llvm-svn: 144918
2011-11-18 03:41:57 +08:00
if (log)
log->Printf ("Host::StartMonitoringChildProcess (callback=%p, baton=%p, pid=%i, monitor_signals=%i) source = %p\n",
callback,
callback_baton,
(int)pid,
monitor_signals,
source);
Made the darwin host layer properly reap any child processes that it spawns. After recent changes we weren't reaping child processes resulting in many zombie processes. This was fixed by adding more settings to the ProcessLaunchOptions class that allow clients to specify a callback function and baton to be notified when their process dies. If one is not supplied a default callback will be used that "does the right thing". Cleaned up a race condition in the ProcessGDBRemote class that would attempt to monitor when debugserver died. Added an extra boolean to the process monitor callbacks that indicate if a process exited or not. If your process exited with a zero exit status and no signal, both items could be zero. Modified the process monitor functions to not require a callback function in order to reap the child process. llvm-svn: 144780
2011-11-16 13:37:56 +08:00
if (source)
{
::dispatch_source_set_cancel_handler (source, ^{
::dispatch_release (source);
});
::dispatch_source_set_event_handler (source, ^{
int status= 0;
int wait_pid = 0;
bool cancel = false;
bool exited = false;
do
{
wait_pid = ::waitpid (pid, &status, 0);
} while (wait_pid < 0 && errno == EINTR);
if (wait_pid >= 0)
{
int signal = 0;
int exit_status = 0;
const char *status_cstr = NULL;
if (WIFSTOPPED(status))
{
signal = WSTOPSIG(status);
status_cstr = "STOPPED";
}
else if (WIFEXITED(status))
{
exit_status = WEXITSTATUS(status);
status_cstr = "EXITED";
exited = true;
}
else if (WIFSIGNALED(status))
{
signal = WTERMSIG(status);
status_cstr = "SIGNALED";
exited = true;
exit_status = -1;
}
else
{
status_cstr = "???";
}
if (log)
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. llvm-svn: 145644
2011-12-02 07:28:38 +08:00
log->Printf ("::waitpid (pid = %llu, &status, 0) => pid = %i, status = 0x%8.8x (%s), signal = %i, exit_status = %i",
Made the darwin host layer properly reap any child processes that it spawns. After recent changes we weren't reaping child processes resulting in many zombie processes. This was fixed by adding more settings to the ProcessLaunchOptions class that allow clients to specify a callback function and baton to be notified when their process dies. If one is not supplied a default callback will be used that "does the right thing". Cleaned up a race condition in the ProcessGDBRemote class that would attempt to monitor when debugserver died. Added an extra boolean to the process monitor callbacks that indicate if a process exited or not. If your process exited with a zero exit status and no signal, both items could be zero. Modified the process monitor functions to not require a callback function in order to reap the child process. llvm-svn: 144780
2011-11-16 13:37:56 +08:00
pid,
wait_pid,
status,
status_cstr,
signal,
exit_status);
if (callback)
cancel = callback (callback_baton, pid, exited, signal, exit_status);
Ran the static analyzer on the codebase and found a few things. llvm-svn: 160338
2012-07-17 11:23:13 +08:00
if (exited || cancel)
Made the darwin host layer properly reap any child processes that it spawns. After recent changes we weren't reaping child processes resulting in many zombie processes. This was fixed by adding more settings to the ProcessLaunchOptions class that allow clients to specify a callback function and baton to be notified when their process dies. If one is not supplied a default callback will be used that "does the right thing". Cleaned up a race condition in the ProcessGDBRemote class that would attempt to monitor when debugserver died. Added an extra boolean to the process monitor callbacks that indicate if a process exited or not. If your process exited with a zero exit status and no signal, both items could be zero. Modified the process monitor functions to not require a callback function in order to reap the child process. llvm-svn: 144780
2011-11-16 13:37:56 +08:00
{
::dispatch_source_cancel(source);
}
}
});
::dispatch_resume (source);
}
return thread;
}
Added code in the Host layer that can report system log messages so that we don't have "fprintf (stderr, ...)" calls sprinkled everywhere. Changed all needed locations over to using this. For non-darwin, we log to stderr only. On darwin, we log to stderr _and_ to ASL (Apple System Log facility). This will allow GUI apps to have a place for these error and warning messages to go, and also allows the command line apps to log directly to the terminal. llvm-svn: 147596
2012-01-05 11:57:59 +08:00
//----------------------------------------------------------------------
// Log to both stderr and to ASL Logging when running on MacOSX.
//----------------------------------------------------------------------
void
Host::SystemLog (SystemLogType type, const char *format, va_list args)
{
if (format && format[0])
{
static aslmsg g_aslmsg = NULL;
if (g_aslmsg == NULL)
{
g_aslmsg = ::asl_new (ASL_TYPE_MSG);
char asl_key_sender[PATH_MAX];
snprintf(asl_key_sender, sizeof(asl_key_sender), "com.apple.LLDB.framework");
::asl_set (g_aslmsg, ASL_KEY_SENDER, asl_key_sender);
}
// Copy the va_list so we can log this message twice
va_list copy_args;
va_copy (copy_args, args);
// Log to stderr
::vfprintf (stderr, format, copy_args);
va_end (copy_args);
int asl_level;
switch (type)
{
case eSystemLogError:
asl_level = ASL_LEVEL_ERR;
break;
case eSystemLogWarning:
asl_level = ASL_LEVEL_WARNING;
break;
}
// Log to ASL
::asl_vlog (NULL, g_aslmsg, asl_level, format, args);
}
}
Added the POSIX-DYLD as a plug-in in the darwin build in the Xcode project so that we don't break it with code changes. After doing this I was able to fix the POSIX-DYLD plug-in so that it builds after recent ModuleSpec changes. llvm-svn: 151536
2012-02-28 03:00:34 +08:00
lldb::DataBufferSP
Host::GetAuxvData(lldb_private::Process *process)
{
return lldb::DataBufferSP();
}
merge lldb-platform-work branch (and assorted fixes) into trunk Summary: This merge brings in the improved 'platform' command that knows how to interface with remote machines; that is, query OS/kernel information, push and pull files, run shell commands, etc... and implementation for the new communication packets that back that interface, at least on Darwin based operating systems via the POSIXPlatform class. Linux support is coming soon. Verified the test suite runs cleanly on Linux (x86_64), build OK on Mac OS X Mountain Lion. Additional improvements (not in the source SVN branch 'lldb-platform-work'): - cmake build scripts for lldb-platform - cleanup test suite - documentation stub for qPlatform_RunCommand - use log class instead of printf() directly - reverted work-in-progress-looking changes from test/types/TestAbstract.py that work towards running the test suite remotely. - add new logging category 'platform' Reviewers: Matt Kopec, Greg Clayton Review: http://llvm-reviews.chandlerc.com/D1493 llvm-svn: 189295
2013-08-27 07:57:52 +08:00
uint32_t
Host::MakeDirectory (const char* path, mode_t mode)
{
return ::mkdir(path,mode);
}