summaryrefslogtreecommitdiffstats
path: root/lldb/source/Target/Platform.cpp
Commit message (Collapse)AuthorAgeFilesLines
...
* sweep up -Wformat warnings from gccSaleem Abdulrasool2014-04-041-2/+2
| | | | | | | This is a purely mechanical change explicitly casting any parameters for printf style conversion. This cleans up the warnings emitted by gcc 4.8 on Linux. llvm-svn: 205607
* Remove an assertion that was being hit due to slow DNS name lookups on ↵Greg Clayton2014-02-271-1/+1
| | | | | | | | | | MacOSX for "localhost". Changed all "localhost" to "127.0.0.1" to prevent potentially long name lookups. <rdar://problem/16154630> llvm-svn: 202424
* Change the way the m_trap_handlers Platform base class ivar is initialized;Jason Molenda2014-02-131-1/+14
| | | | | | | | add a new pure virtual CalculateTrapHandlerSymbolNames() that Platform subclasses must implement which fills in the function name list with any trap handlers that are expected on that platform. llvm-svn: 201364
* The Platform base class now maintains a list of trap handlersJason Molenda2014-02-131-1/+2
| | | | | | | | | | | | | | | | aka asynchronous signal handlers, which subclasses should fill in as appropriate. For most Unix user process environments, the one entry in this list is _sigtramp. For bare-board and kernel environments, there will be different sets of trap handlers. The unwinder needs to know when a frame is a trap handler because the rules it enforces for the frame "above" the trap handler is different from most middle-of-the-stack frames. <rdar://problem/15835846> llvm-svn: 201300
* Merging the iohandler branch back into main. Greg Clayton2014-01-271-0/+2
| | | | | | | | | | | | The many many benefits include: 1 - Input/Output/Error streams are now handled as real streams not a push style input 2 - auto completion in python embedded interpreter 3 - multi-line input for "script" and "expression" commands now allow you to edit previous/next lines using up and down arrow keys and this makes multi-line input actually a viable thing to use 4 - it is now possible to use curses to drive LLDB (please try the "gui" command) We will need to deal with and fix any buildbot failures and tests and arise now that input/output and error are correctly hooked up in all cases. llvm-svn: 200263
* Rename Platform::GetFile (3-arg version) to GetFileWithUUIDSteve Pucci2014-01-171-3/+3
| | | | | | | | | | | This rename was suggested by gclayton as a way to silence gcc warnings; the warning is emitted when there is an overloaded function in a base class (Platform) for which a derived class redefines one of the overloads but not the other (because doing so hides the other overload from users of the derived class). By giving the two methods different names, the situation is avoided. llvm-svn: 199504
* Fixed internal code to not link against and code from "lldb/API/*". Greg Clayton2013-12-021-0/+14
| | | | | | | | | | lldb_private::Debugger was #including some "lldb/API" header files which causes tools (lldb-platform and lldb-gdbserver) that link against the internals only (no API layer) to fail to link depending on which calls were being used. Also fixed the current working directory so that it gets set correctly for remote test suite runs. Now the remote working directory is set to: "ARCH/TESTNUM/..." where ARCH is the current architecture name and "TESTNUM" is the current test number. Fixed the "lldb-platform" and "lldb-gdbserver" to not warn about mismatched visibility settings by having each have their own exports file which contains nothing. This forces all symbols to not be exported, and also quiets the linker warnings. llvm-svn: 196141
* Fix MSVC buildColin Riley2013-11-261-0/+5
| | | | | | Added _WIN32 guards to new platform features. Using correct SetErrorStringWithFormat within Host when LLDB_DISABLE_POSIX is defined. Also fixed an if defined block. llvm-svn: 195766
* Expose SBPlatform through the public API.Greg Clayton2013-11-201-12/+337
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Example code: remote_platform = lldb.SBPlatform("remote-macosx"); remote_platform.SetWorkingDirectory("/private/tmp") debugger.SetSelectedPlatform(remote_platform) connect_options = lldb.SBPlatformConnectOptions("connect://localhost:1111"); err = remote_platform.ConnectRemote(connect_options) if err.Success(): print >> result, 'Connected to remote platform:' print >> result, 'hostname: %s' % (remote_platform.GetHostname()) src = lldb.SBFileSpec("/Applications/Xcode.app/Contents/SharedFrameworks/LLDB.framework", False) dst = lldb.SBFileSpec() # copy src to platform working directory since "dst" is empty err = remote_platform.Install(src, dst); if err.Success(): print >> result, '%s installed successfully' % (src) else: print >> result, 'error: failed to install "%s": %s' % (src, err) Implemented many calls needed in lldb-platform to be able to install a directory that contains symlinks, file and directories. The remote lldb-platform can now launch GDB servers on the remote system so that remote debugging can be spawned through the remote platform when connected to a remote platform. The API in SBPlatform is subject to change and will be getting many new functions. llvm-svn: 195273
* Turns out the number of times you need to resume the process for /bin/sh ↵Jim Ingham2013-09-111-1/+1
| | | | | | | | | | depends on the setting of the environment variable COMMAND_MODE. Changed the Platform::GetResumeCountForShell to Platform::GetResumeCountForLaunchInfo, and check both the shell and in the case of /bin/sh the environment as well. llvm-svn: 190538
* Changing the default shell to /bin/sh brought up a long-standing bug on OS X,Jim Ingham2013-09-101-1/+3
| | | | | | | | | | | | | that /bin/sh re-exec's itself to /bin/bash, so it needs one more resume when you are using it as the shell than /bin/bash did or you will stop at the start of your program, rather than running it. So I added a Platform API to get the number of resumes needed when launching with a particular shell, and set the right values for Mac OS X. <rdar://problem/14935282> llvm-svn: 190381
* Add OptionParser.hVirgile Bello2013-09-051-7/+7
| | | | llvm-svn: 190063
* merge lldb-platform-work branch (and assorted fixes) into trunkDaniel Malea2013-08-261-2/+267
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Fix various build warnings.Matt Kopec2013-06-031-1/+1
| | | | llvm-svn: 183140
* <rdar://problem/13854277>Greg Clayton2013-05-101-10/+11
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | <rdar://problem/13594769> Main changes in this patch include: - cleanup plug-in interface and use ConstStrings for plug-in names - Modfiied the BSD Archive plug-in to be able to pick out the correct .o file when .a files contain multiple .o files with the same name by using the timestamp - Modified SymbolFileDWARFDebugMap to properly verify the timestamp on .o files it loads to ensure we don't load updated .o files and cause problems when debugging The plug-in interface changes: Modified the lldb_private::PluginInterface class that all plug-ins inherit from: Changed: virtual const char * GetPluginName() = 0; To: virtual ConstString GetPluginName() = 0; Removed: virtual const char * GetShortPluginName() = 0; - Fixed up all plug-in to adhere to the new interface and to return lldb_private::ConstString values for the plug-in names. - Fixed all plug-ins to return simple names with no prefixes. Some plug-ins had prefixes and most ones didn't, so now they all don't have prefixed names, just simple names like "linux", "gdb-remote", etc. llvm-svn: 181631
* Cleanup logging to use the new "std::string FileSpec::GetPath()" function. ↵Greg Clayton2013-04-291-4/+2
| | | | | | | | | | | 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
* After discussing with Chris Lattner, we require C++11, so lets get rid of ↵Greg Clayton2013-04-181-2/+2
| | | | | | the macros and just use C++11. llvm-svn: 179805
* Since we use C++11, we should switch over to using std::unique_ptr when ↵Greg Clayton2013-04-181-2/+2
| | | | | | | | C++11 is being used. To do this, we follow what we have done for shared pointers and we define a STD_UNIQUE_PTR macro that can be used and it will "do the right thing". Due to some API differences in std::unique_ptr and due to the fact that we need to be able to compile without C++11, we can't use move semantics so some code needed to change so that it can compile with either C++. Anyone wanting to use a unique_ptr or auto_ptr should now use the "STD_UNIQUE_PTR(TYPE)" macro. llvm-svn: 179779
* Add a new PlatformDarwinKernel for kernel debugging. This PlatformJason Molenda2013-04-051-0/+31
| | | | | | | | | | | | | | | | | | | | | plugin will index the kext bundles on the local filesystem when created. During a kernel debug session, when the DynamicLoader plugin needs to locate a kext by name like "com.apple.com.apple.filesystems.autofs", the Platform can quickly look for a UUID match in those kernel debug kit directories it previously indexed. I'm still working on profiling the performance impact of the inital kext bundle scan; there will likely need to be a switch to enable or disable this plugin's scan. This only affects Mac kernel debugging and the code is only built on Apple systems because of some use of low-level CoreFoundation to parse plists. <rdar://problem/13503583> llvm-svn: 178827
* <rdar://problem/13521159>Greg Clayton2013-03-271-2/+2
| | | | | | | | 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
* <rdar://problem/12973809> Greg Clayton2013-01-111-3/+3
| | | | | | | | | | | | | Fixed an issue with the auto loading of script resources in debug info files. Any platform can add support for this, and on MacOSX we allow dSYM files to contain python modules that get automatically loaded when a dSYM file is associated with an executable or shared library. The modifications will now: - Let the module locate the symbol file naturally instead of using a function that only works in certain cases. This helps us to locate the script resources as long as the dSYM file can be found. - Don't try and do any of this if the script interpreter has scripting disabled. - Allow more than one scripting resource to be found in a symbol file by returning the list - Load the scripting resources when a symbol file is added via the "target symbols add" command. - Be smarter about matching the dSYM mach-o file to an existing executable in the target images by stripping extensions on the symfile basname if needed. llvm-svn: 172275
* <rdar://problem/12990038>Greg Clayton2013-01-111-8/+40
| | | | | | Fixed an issue where the platform auto select code was changing the architecture and causing the wrong architecture to be assigned to the target. llvm-svn: 172251
* Removed the == and != operators from ArchSpec, sinceSean Callanan2012-12-131-1/+1
| | | | | | | | | | | | equality can be strict or loose and we want code to explicitly choose one or the other. Also renamed the Compare function to IsEqualTo, to avoid confusion. <rdar://problem/12856749> llvm-svn: 170152
* <rdar://problem/12586350>Enrico Granata2012-11-081-0/+6
| | | | | | | | | | | | | | This commit does three things: (a) introduces a new notification model for adding/removing/changing modules to a ModuleList, and applies it to the Target's ModuleList, so that we make sure to always trigger the right set of actions whenever modules come and go in a target. Certain spots in the code still need to "manually" notify the Target for several reasons, so this is a work in progress (b) adds a new capability to the Platforms: locating a scripting resources associated to a module. A scripting resource is a Python file that can load commands, formatters, ... and any other action of interest corresponding to the loading of a module. At the moment, this is only implemented on Mac OS X and only for files inside .dSYM bundles - the next step is going to be letting the frameworks themselves hold their scripting resources. Implementors of platforms for other systems are free to implement "the right thing" for their own worlds (c) hooking up items (a) and (b) so that targets auto-load the scripting resources as the corresponding modules get loaded in a target. This has a few caveats at the moment: - the user needs to manually add the .py file to the dSYM (soon, it will also work in the framework itself) - if two modules with the same name show up during the lifetime of an LLDB session, the second one won't be able to load its scripting resource, but will otherwise work just fine llvm-svn: 167569
* <rdar://problem/11374963>Greg Clayton2012-09-121-0/+16
| | | | | | Partial fix for the above radar where we now resolve dsym mach-o files within the dSYM bundle when using "add-dsym" through the platform. llvm-svn: 163676
* <rdar://problem/11757916>Greg Clayton2012-08-291-0/+1
| | | | | | | | | | | | Make breakpoint setting by file and line much more efficient by only looking for inlined breakpoint locations if we are setting a breakpoint in anything but a source implementation file. Implementing this complex for a many reasons. Turns out that parsing compile units lazily had some issues with respect to how we need to do things with DWARF in .o files. So the fixes in the checkin for this makes these changes: - Add a new setting called "target.inline-breakpoint-strategy" which can be set to "never", "always", or "headers". "never" will never try and set any inlined breakpoints (fastest). "always" always looks for inlined breakpoint locations (slowest, but most accurate). "headers", which is the default setting, will only look for inlined breakpoint locations if the breakpoint is set in what are consudered to be header files, which is realy defined as "not in an implementation source file". - modify the breakpoint setting by file and line to check the current "target.inline-breakpoint-strategy" setting and act accordingly - Modify compile units to be able to get their language and other info lazily. This allows us to create compile units from the debug map and not have to fill all of the details in, and then lazily discover this information as we go on debuggging. This is needed to avoid parsing all .o files when setting breakpoints in implementation only files (no inlines). Otherwise we would need to parse the .o file, the object file (mach-o in our case) and the symbol file (DWARF in the object file) just to see what the compile unit was. - modify the "SymbolFileDWARFDebugMap" to subclass lldb_private::Module so that the virtual "GetObjectFile()" and "GetSymbolVendor()" functions can be intercepted when the .o file contenst are later lazilly needed. Prior to this fix, when we first instantiated the "SymbolFileDWARFDebugMap" class, we would also make modules, object files and symbol files for every .o file in the debug map because we needed to fix up the sections in the .o files with information that is in the executable debug map. Now we lazily do this in the DebugMapModule::GetObjectFile() Cleaned up header includes a bit as well. llvm-svn: 162860
* Reimplemented the code that backed the "settings" in lldb. There were many ↵Greg Clayton2012-08-221-0/+7
| | | | | | | | | | | | | issues with the previous implementation: - no setting auto completion - very manual and error prone way of getting/setting variables - tons of code duplication - useless instance names for processes, threads Now settings can easily be defined like option values. The new settings makes use of the "OptionValue" classes so we can re-use the option value code that we use to set settings in command options. No more instances, just "does the right thing". llvm-svn: 162366
* When the Platform launches a process for debugging, make sure it goes into a ↵Jim Ingham2012-06-011-0/+5
| | | | | | | | 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
* <rdar://problem/11240464>Greg Clayton2012-05-151-0/+6
| | | | | | Correctly unique a class' methods when we detect that a class has been uniqued to another. llvm-svn: 156795
* <rdar://problem/11358639>Greg Clayton2012-05-081-14/+24
| | | | | | | | Switch over to the "*-apple-macosx" for desktop and "*-apple-ios" for iOS triples. Also make the selection process for auto selecting platforms based off of an arch much better. llvm-svn: 156354
* Added a new host function that allows us to run shell command and get the ↵Greg Clayton2012-04-141-1/+6
| | | | | | | | | | | | | | | | output from them along with the status and signal: Error Host::RunShellCommand (const char *command, const char *working_dir, int *status_ptr, int *signo_ptr, std::string *command_output_ptr, uint32_t timeout_sec); This will allow us to use this functionality in the host lldb_private::Platform, and also use it in our lldb-platform binary. It leverages the existing code in Host::LaunchProcess and ProcessLaunchInfo. llvm-svn: 154730
* <rdar://problem/11113279>Greg Clayton2012-03-261-0/+12
| | | | | | | | | | Fixed type lookups to "do the right thing". Prior to this fix, looking up a type using "foo::bar" would result in a type list that contains all types that had "bar" as a basename unless the symbol file was able to match fully qualified names (which our DWARF parser does not). This fix will allow type matches to be made based on the basename and then have the types that don't match filtered out. Types by name can be fully qualified, or partially qualified with the new "bool exact_match" parameter to the Module::FindTypes() method. This fixes some issue that we discovered with dynamic type resolution as well as improves the overall type lookups in LLDB. llvm-svn: 153482
* Platforms can now auto-select themselves if you specify a full target triple ↵Greg Clayton2012-03-201-2/+57
| | | | | | | | when doing a "target create" command. Each platform now knows if it can handle an architecture and a platform can be found using an architecture. Each platform can look at the arch, vendor and OS and know if it should be used or not. llvm-svn: 153104
* Made a ModuleSpec class in Module.h which can specify a module using one orGreg Clayton2012-02-261-23/+7
| | | | | | | | | | | | | | | | | | more of the local path, platform path, associated symbol file, UUID, arch, object name and object offset. This allows many of the calls that were GetSharedModule to reduce the number of arguments that were used in a call to these functions. It also allows a module to be created with a ModuleSpec which allows many things to be specified prior to any accessors being called on the Module class itself. I was running into problems when adding support for "target symbol add" where you can specify a stand alone debug info file after debugging has started where I needed to specify the associated symbol file path and if I waited until after construction, the wrong symbol file had already been located. By using the ModuleSpec it allows us to construct a module with as little or as much information as needed and not have to change the parameter list. llvm-svn: 151476
* Full core file support has been added for mach-o core files.Greg Clayton2012-02-131-1/+6
| | | | | | | | | | | | | | | | 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
* Use a pseudoterminal for local processes if no STDIO redirection or otherGreg Clayton2011-11-171-0/+10
| | | | | | file actions have been specified. llvm-svn: 144922
* Fixed the issue that was causing our monitor process threads to crash, it Greg Clayton2011-11-171-0/+8
| | | | | | | | | | turned out to be unitialized data in the ProcessLaunchInfo default constructor. Turning on MallocScribble in the environment helped track this down. When we launch and attach using the host layer, we now inform the process that it shouldn't detach when by calling an accessor. llvm-svn: 144882
* Added a new class to Process.h: ProcessAttachInfo. This class contains enoughGreg Clayton2011-11-151-9/+3
| | | | | | | | | | | | | | | | | | | | | 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
* Added the ability for the target to specify Modules that will not be searchedJim Ingham2011-10-281-1/+0
| | | | | | | when setting breakpoints, but only if no module is specified. The Darwin platform uses this to not set breakpoints in dyld. llvm-svn: 143249
* Patch for "process load" by Filipe Cabecinhas.Greg Clayton2011-08-111-0/+8
| | | | | | | | | | | | | | | | | | | | | Filipe was attempting to do a: (lldb) process load ~/path/foo.dylib But the process load command wasn't resolving the path. We have to be careful about resolving the path here because we want to do it in terms of the platform we are using. the "~/" can mean a completely different path if you are remotely debugging on another machine as another user. So to support this, platforms now can resolve remote paths: bool Platform::ResolveRemotePath (const FileSpec &platform_path, FileSpec &resolved_platform_path); The host/local platform will just resolve the path. llvm-svn: 137307
* Added the notion of an system root for SDKs. This is a directory where allGreg Clayton2011-06-171-0/+2
| | | | | | | | | | | | | | | | libraries and headers exist. This can be specified using the platform select function: platform select --sysroot /Volumes/remote-root remote-macosx Each platform subclass is free to interpret the sysroot as needed. Expose the new SDK root directory through the SBDebugger class. Fixed an issue with the GDB remote protocol where unimplemented packets were not being handled correctly. llvm-svn: 133231
* Added auto completion for architecture names and for platforms.Greg Clayton2011-04-131-5/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Modified the OptionGroupOptions to be able to specify only some of the options that should be appended by using the usage_mask in the group defintions and also provided a way to remap them to a new usage mask after the copy. This allows options to be re-used and also targetted for specific option groups. Modfied the CommandArgumentType to have a new eArgTypePlatform enumeration. Taught the option parser to be able to automatically use the appropriate auto completion for a given options if nothing is explicitly specified in the option definition. So you don't have to specify it in the option definition tables. Renamed the default host platform name to "host", and the default platform hostname to be "localhost". Modified the "file" and "platform select" commands to make sure all options and args are good prior to creating a new platform. Also defer the computation of the architecture in the file command until all options are parsed and the platform has either not been specified or reset to a new value to avoid computing the arch more than once. Switch the PluginManager code over to using llvm::StringRef for string comparisons and got rid of all the AccessorXXX functions in lieu of the newer mutex + collection singleton accessors. llvm-svn: 129483
* Moved the execution context that was in the Debugger intoGreg Clayton2011-04-121-4/+66
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Many improvements to the Platform base class and subclasses. The base PlatformGreg Clayton2011-03-301-32/+101
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Did a lot more work on abtracting and organizing the platforms. Greg Clayton2011-03-241-9/+103
| | | | | | | | | | | | | | | | | | | | 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
* Added new platform commands:Greg Clayton2011-03-231-5/+14
| | | | | | | | | | | | | | | | platform connect <args> platform disconnect Each platform can decide the args they want to use for "platform connect". I will need to add a function that gets the connect options for the current platform as each one can have different options and argument counts. Hooked up more functionality in the PlatformMacOSX and PlatformRemoteiOS. Also started an platform agnostic PlatformRemoteGDBServer.cpp which can end up being used by one or more actual platforms. It can also be specialized and allow for platform specific commands. llvm-svn: 128123
* Added more platform support. There are now some new commands:Greg Clayton2011-03-191-37/+153
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provideGreg Clayton2011-03-081-0/+230
an interface to a local or remote debugging platform. By default each host OS that supports LLDB should be registering a "default" platform that will be used unless a new platform is selected. Platforms are responsible for things such as: - getting process information by name or by processs ID - finding platform files. This is useful for remote debugging where there is an SDK with files that might already or need to be cached for debug access. - getting a list of platform supported architectures in the exact order they should be selected. This helps the native x86 platform on MacOSX select the correct x86_64/i386 slice from universal binaries. - Connect to remote platforms for remote debugging - Resolving an executable including finding an executable inside platform specific bundles (macosx uses .app bundles that contain files) and also selecting the appropriate slice of universal files for a given platform. So by default there is always a local platform, but remote platforms can be connected to. I will soon be adding a new "platform" command that will support the following commands: (lldb) platform connect --name machine1 macosx connect://host:port Connected to "machine1" platform. (lldb) platform disconnect macosx This allows LLDB to be well setup to do remote debugging and also once connected process listing and finding for things like: (lldb) process attach --name x<TAB> The currently selected platform plug-in can now auto complete any available processes that start with "x". The responsibilities for the platform plug-in will soon grow and expand. llvm-svn: 127286
OpenPOWER on IntegriCloud