summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Platform/Linux/PlatformLinux.h
Commit message (Collapse)AuthorAgeFilesLines
* [lldb] Decouple importing the std C++ module from the way the program is ↵Raphael Isemann2019-09-241-3/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | compiled Summary: At the moment, when trying to import the `std` module in LLDB, we look at the imported modules used in the compiled program and try to infer the Clang configuration we need from the DWARF module-import. That was the initial idea but turned out to cause a few problems or inconveniences: * It requires that users compile their programs with C++ modules. Given how experimental C++ modules are makes this feature inaccessible for many users. Also it means that people can't just get the benefits of this feature for free when we activate it by default (and we can't just close all the associated bug reports). * Relying on DWARF's imported module tags (that are only emitted by default on macOS) means this can only be used when using DWARF (and with -glldb on Linux). * We essentially hardcoded the C standard library paths on some platforms (Linux) or just couldn't support this feature on other platforms (macOS). This patch drops the whole idea of looking at the imported module DWARF tags and instead just uses the support files of the compilation unit. If we look at the support files and see file paths that indicate where the C standard library and libc++ are, we can just create the module configuration this information. This fixes all the problems above which means we can enable all the tests now on Linux, macOS and with other debug information than what we currently had. The only debug information specific code is now the iteration over external type module when -gmodules is used (as `std` and also the `Darwin` module are their own external type module with their own files). The meat of this patch is the CppModuleConfiguration which looks at the file paths from the compilation unit and then figures out the include paths based on those paths. It's quite conservative in that it only enables modules if we find a single C library and single libc++ library. It's still missing some test mode where we try to compile an expression before we actually activate the config for the user (which probably also needs some caching mechanism), but for now it works and makes the feature usable. Reviewers: aprantl, shafik, jdoerfert Reviewed By: aprantl Subscribers: mgorny, abidh, JDevlieghere, lldb-commits Tags: #c_modules_in_lldb, #lldb Differential Revision: https://reviews.llvm.org/D67760 llvm-svn: 372716
* [NFC] Remove ASCII lines from commentsJonas Devlieghere2019-04-101-4/+0
| | | | | | | | | | | | | | | | | | | | | | | A lot of comments in LLDB are surrounded by an ASCII line to delimit the begging and end of the comment. Its use is not really consistent across the code base, sometimes the lines are longer, sometimes they are shorter and sometimes they are omitted. Furthermore, it looks kind of weird with the 80 column limit, where the comment actually extends past the line, but not by much. Furthermore, when /// is used for Doxygen comments, it looks particularly odd. And when // is used, it incorrectly gives the impression that it's actually a Doxygen comment. I assume these lines were added to improve distinguishing between comments and code. However, given that todays editors and IDEs do a great job at highlighting comments, I think it's worth to drop this for the sake of consistency. The alternative is fixing all the inconsistencies, which would create a lot more churn. Differential revision: https://reviews.llvm.org/D60508 llvm-svn: 358135
* Add ability to import std module into expression parser to improve C++ debuggingRaphael Isemann2019-03-121-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This patch is the MVP version of importing the std module into the expression parser to improve C++ debugging. What happens in this patch is that we inject a `@import std` into our expression source code. We also modify our internal Clang instance for parsing this expression to work with modules and debug info at the same time (which is the main change in terms of LOC). We implicitly build the `std` module on the first use. The C++ include paths for building are extracted from the debug info, which means that this currently only works if the program is compiled with `-glldb -fmodules` and uses the std module. The C include paths are currently specified by LLDB. I enabled the tests currently only for libc++ and Linux because I could test this locally. I'll enable the tests for other platforms once this has landed and doesn't break any bots (and I implemented the platform-specific C include paths for them). With this patch we can now: * Build a libc++ as a module and import it into the expression parser. * Read from the module while also referencing declarations from the debug info. E.g. `std::abs(local_variable)`. What doesn't work (yet): * Merging debug info and C++ module declarations. E.g. `std::vector<CustomClass>` doesn't work. * Pretty much anything that involves the ASTImporter and templated code. As the ASTImporter is used for saving the result declaration, this means that we can't call yet any function that returns a non-trivial type. * Use libstdc++ for this, as it requires multiple include paths and Clang only emits one include path per module. Also libstdc++ doesn't support Clang modules without patches. Reviewers: aprantl, jingham, shafik, friss, davide, serge-sans-paille Reviewed By: aprantl Subscribers: labath, mgorny, abidh, jdoerfert, lldb-commits Tags: #c_modules_in_lldb, #lldb Differential Revision: https://reviews.llvm.org/D58125 llvm-svn: 355939
* Update the file headers across all of the LLVM projects in the monorepoChandler Carruth2019-01-191-4/+3
| | | | | | | | | | | | | | | | | to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
* Make i386-*-freebsd expression work on JIT pathEd Maste2017-08-161-2/+4
| | | | | | | | | | | | | | | | * Enable i386 ABI creation for freebsd * Added an extra argument in ABISysV_i386::PrepareTrivialCall for mmap syscall * Unlike linux, the last argument of mmap is actually 64-bit(off_t). This requires us to push an additional word for the higher order bits. * Prior to this change, ktrace dump will show mmap failures due to invalid argument coming from the 6th mmap argument. Patch by Karnajit Wangkhem Differential Revision: https://reviews.llvm.org/D34776 llvm-svn: 311002
* Rename Error -> Status.Zachary Turner2017-05-121-1/+1
| | | | | | | | | | | | | | | This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
* Clean up PlatformLinux codePavel Labath2017-02-051-6/+0
| | | | | | | | don't create a platform.linux setting category, as it contains no actual settings, and I don't forsee adding any soon. Also remove some unused includes while I'm in there. llvm-svn: 294114
* Push down more common code into PlatformPOSIXPavel Labath2017-02-031-10/+0
| | | | | | | | | | | | | | | | | | | | Summary: - GetFileWithUUID: All platforms except PlatformDarwin had this. However, I see no reason why this code would not apply there as well. - GetProcessInfo, FindProcesses: The implementation was the same in all classes. - GetFullNameForDylib: This code should apply to all non-darwin platforms. I've kept the PlatformDarwin override as the situation is different there. Reviewers: clayborg, krytarowski, emaste Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D29496 llvm-svn: 294019
* Unify PlatformPOSIX::ResolveExecutablePavel Labath2017-02-021-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: various platforms very using nearly identical code for this method. As far as I can tell there was nothing platform-specific about the differences, but rather it looked like it was caused by tiny tweaks being made to individual copies without affecting the overall functionality. I have taken the superset of all these tweaks and put it into one method in the base class (incidentaly, nobody was using the base class implementation of the method, as all classes were overriding it). From the darwin class I took the slightly improved error reporting (checking whether the file is readable) and the ResolveExecutableInBundle call (which has no effect elsewhere as the function is already a no-op on non-darwin platforms). From the linux class I took the set-the-triple-vendor-to-host-if-unspecified tweak (present in PlatformKalimba as well). PlatformWindows has an identical copy as well. We could resolve that by pushing this code further down into Platform class, that that would require pushing the m_remote_platform_sp member as well, which seems like a bad design choice. Reviewers: clayborg, emaste, krytarowski Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D29406 llvm-svn: 293910
* *** This commit represents a complete reformatting of the LLDB source codeKate Stone2016-09-061-92/+66
| | | | | | | | | | | | | | | | | | | | | | | *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
* Refactor GetSoftwareBreakpointTrapOpcodeAidan Dodds2016-02-221-4/+0
| | | | | | | | This patch aims to reduce the code duplication among all of the platforms in GetSoftwareBreakpointTrapOpcode by pushing all common code into the Platform base class. Differential Revision: http://reviews.llvm.org/D17395 llvm-svn: 261536
* Fix Clang-tidy modernize-use-override warnings in ↵Eugene Zelenko2015-10-271-6/+4
| | | | | | source/Plugins/LanguageRuntime and Platform; other minor fixes. llvm-svn: 251374
* Add functionality to the platforms to figure out the proper name for a ↵Enrico Granata2015-08-271-0/+3
| | | | | | | | | | | | | | | | dynamic library on the system given a basename This will do things like, given mylibrary, return libmylibrary.dylib on OSX mylibrary.dll on Windows and so on for other platforms It is currently implemented for Windows, Darwin, and Linux. Other platforms should fill in accordingly llvm-svn: 246131
* Avoid going through Platform when creating a NativeProcessProtocol instancePavel Labath2015-07-091-11/+0
| | | | | | | | | | | | | | | | | | | | | | | | Summary: This commit avoids the Platform instance when spawning or attaching to a process in lldb-server. Instead, I have the server call a (static) method of NativeProcessProtocol directly. The reason for this is that I believe that NativeProcessProtocol should be decoupled from the Platform (after all, it always knows which platform it is running on, unlike the rest of lldb). Additionally, the kind of platform actions a NativeProcessProtocol instance is likely to differ greatly from the platform actions of the lldb client, so I think the separation makes sense. After this, the only dependency NativeProcessLinux has on PlatformLinux is the ResolveExecutable method, which needs additional refactoring. This is a resubmit of r241672, after it was reverted due to build failueres on non-linux platforms. Reviewers: ovyalov, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D10996 llvm-svn: 241796
* Revert r241672, which breaks the OS X build by introducing a dependency onSean Callanan2015-07-081-0/+11
| | | | | | | | | | | | | | | | platform-specific symbols that are not implemented on OS X. The build error that caused this is Undefined symbols for architecture x86_64: "lldb_private::NativeProcessProtocol::Attach(unsigned long long, lldb_private::NativeProcessProtocol::NativeDelegate&, std::__1::shared_ptr<lldb_private::NativeProcessProtocol>&)", referenced from: lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS::AttachToProcess(unsigned long long) in liblldb-core.a(GDBRemoteCommunicationServerLLGS.o) "lldb_private::NativeProcessProtocol::Launch(lldb_private::ProcessLaunchInfo&, lldb_private::NativeProcessProtocol::NativeDelegate&, std::__1::shared_ptr<lldb_private::NativeProcessProtocol>&)", referenced from: lldb_private::process_gdb_remote::GDBRemoteCommunicationServerLLGS::LaunchProcess() in liblldb-core.a(GDBRemoteCommunicationServerLLGS.o) ld: symbol(s) not found for architecture x86_64 clang: error: linker command failed with exit code 1 (use -v to see invocation) llvm-svn: 241688
* Avoid going through Platform when creating a NativeProcessProtocol instancePavel Labath2015-07-081-11/+0
| | | | | | | | | | | | | | | | | | | | | Summary: This commit avoids the Platform instance when spawning or attaching to a process in lldb-server. Instead, I have the server call a (static) method of NativeProcessProtocol directly. The reason for this is that I believe that NativeProcessProtocol should be decoupled from the Platform (after all, it always knows which platform it is running on, unlike the rest of lldb). Additionally, the kind of platform actions a NativeProcessProtocol instance is likely to differ greatly from the platform actions of the lldb client, so I think the separation makes sense. After this, the only dependency NativeProcessLinux has on PlatformLinux is the ResolveExecutable method, which needs additional refactoring. Reviewers: ovyalov, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D10996 llvm-svn: 241672
* [LLDB][MIPS] Getting correct flags for MIPSMohit K. Bhakkad2015-06-301-1/+1
| | | | | | | | | | Patch by Nitesh Jain Reviewers: clayborg, ovyalov, emaste. Subscribers: jaydeep, bhushan, dsanders, mohit.bhakkad, sagar, labath, tberghammer, lldb-commits. Differential Revision: http://reviews.llvm.org/D10685 llvm-svn: 241045
* Remove old local-only linux debugging codePavel Labath2015-06-241-3/+0
| | | | | | | | | | | | | | | | | | | | Summary: Currently, the local-only path fails about 50% of the tests, which means that: a) nobody is using it; and b) the remote debugging path is much more stable. This commit removes the local-only linux debugging code (ProcessLinux) and makes remote-loopback the only way to debug local applications (the same architecture as OSX). The ProcessPOSIX code is moved to the FreeBSD directory, which is now the only user of this class. Hopefully, FreeBSD will soon move to the new architecture as well and then this code can be removed completely. Test Plan: Test suite passes via remote stub. Reviewers: emaste, vharron, ovyalov, clayborg Subscribers: tberghammer, emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D10661 llvm-svn: 240543
* Convert mmap options for target in InferiorCallMmap.Robert Flack2015-05-091-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | Converts the MAP_PRIVATE and MAP_ANON options to the target platform constants (on which the call runs) rather than using those of the compiled host. Test Plan: Run test suite, the following tests requiring memory allocation / JIT support begin passing when running mac -> linux: Test11588.py TestAnonymous.py TestBreakpointConditions.py TestCPPStaticMethods.py TestCStrings.py TestCallStdStringFunction.py TestDataFormatterCpp.py TestDataFormatterStdList.py TestExprDoesntBlock.py TestExprHelpExamples.py TestFunctionTypes.py TestPrintfAfterUp.py TestSBValuePersist.py TestSetValues.py Differential Revision: http://reviews.llvm.org/D9511 llvm-svn: 236933
* Move several plugin to its own namespaceTamas Berghammer2015-03-311-7/+10
| | | | | | | | | | | | | Affected paths: * Plugins/Platform/Android/* * Plugins/Platform/Linux/* * Plugins/Platform/gdb-server/* * Plugins/Process/Linux/* * Plugins/Process/gdb-remote/* Differential revision: http://reviews.llvm.org/D8654 llvm-svn: 233679
* Remove EOL whitespace from PlatformLinuxEd Maste2015-02-231-3/+3
| | | | | | This reduces the noise when diffing PlatformFreeBSD and PlatformLinux. llvm-svn: 230251
* Implement remote process listing in Linux platform.Stephane Sezer2014-12-091-0/+4
| | | | | | | | | | | | | | Summary: Test Plan: Connect to a remote implementing the platform protocol (ds2 in this case), run `platform process list` and see processes being displayed. Reviewers: vharron, tfiala, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D6571 llvm-svn: 223752
* Fixed more fallout from running the test suite remotely on iOS devices.Greg Clayton2014-11-171-3/+1
| | | | | | | | | | | | | | | | Fixed include: - Change Platform::ResolveExecutable(...) to take a ModuleSpec instead of a FileSpec + ArchSpec to help resolve executables correctly when we have just a path + UUID (no arch). - Add the ability to set the listener in SBLaunchInfo and SBAttachInfo in case you don't want to use the debugger as the default listener. - Modified all places that use the SBLaunchInfo/SBAttachInfo and the internal ProcessLaunchInfo/ProcessAttachInfo to not take a listener as a parameter since it is in the launch/attach info now - Load a module's sections by default when removing a module from a target. Since we create JIT modules for expressions and helper functions, we could end up with stale data in the section load list if a module was removed from the target as the section load list would still have entries for the unloaded module. Target now has the following functions to help unload all sections a single or multiple modules: size_t Target::UnloadModuleSections (const ModuleList &module_list); size_t Target::UnloadModuleSections (const lldb::ModuleSP &module_sp); llvm-svn: 222167
* Enable local llgs debugging on Linux when the use-llgs-for-local setting is ↵Todd Fiala2014-10-101-6/+12
| | | | | | | | | | | | | | | | | | | enabled. See http://reviews.llvm.org/D5695 for details. This change does the following: Enable lldb-gdbserver (llgs) usage for local-process Linux debugging. To turn on local llgs debugging support, which is disabled by default, enable this setting: (lldb) settings set platform.plugin.linux.use-llgs-for-local true Adds a stream-based Dump() function to FileAction. Pushes some platform methods that Linux (and FreeBSD) will want to share with MacOSX from PlatformDarwin into PlatformPOSIX. Reviewed by Greg Clayton. llvm-svn: 219457
* Test suite runs better again after recent fixes that would select a platform ↵Greg Clayton2014-09-191-1/+1
| | | | | | | | | | | | | if a "file a.out" auto selected a different platform than the selected one. Changes include: - fix it so you can select the "host" platform using "platform select host" - change all callbacks that create platforms to returns shared pointers - fix TestImageListMultiArchitecture.py to restore the "host" platform by running "platform select host" - Add a new "PlatformSP Platform::Find(const ConstString &name)" method to get a cached platform - cache platforms that are created and re-use them instead of always creating a new one llvm-svn: 218145
* Added setting: platform.plugin.linux.use-llgs-for-local (boolean), defaults ↵Todd Fiala2014-08-281-0/+3
| | | | | | | | | to false This setting is not yet hooked up to anything. In preparation for adding/testing llgs for local Linux debugging. llvm-svn: 216690
* Enable lldb-platform exe support for Linux.Todd Fiala2014-07-221-35/+28
| | | | | | | | | | | | | | This change enables lldb-platform for Linux. In addition, it does the following: * fixes Host::GetLLDBPath() to work on Linux/*BSD for ePathTypeSupportExecutableDir-relative paths. * adds more logging and comments around lldb-platform startup and remote lldb-platform usage. * refactors lldb-platform remote-* support for Darwin and Linux into PlatformPOSIX. This, in theory, is the bulk of what is needed for *BSD to make remote connections to lldb-platform as well (although I haven't tested that yet). FreeBSD can make similar changes to their Platform* as was made here for PlatformLinux to pick up the rest of the bits. * teaches GDBRemoteCommunication to use lldb-gdbserver for non-Apple hosts. llvm-svn: 213707
* Add lldb-gdbserver support for Linux x86_64.Todd Fiala2014-06-301-1/+12
| | | | | | | | | | | | | | | | | | | | | This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64. (More architectures coming soon). Not every debugserver option is covered yet. Currently the lldb-gdbserver command line can start unattached, start attached to a pid (process-name attach not supported yet), or accept lldb attaching and launching a process or connecting by process id. The history of this large change can be found here: https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64 Until mid/late April, I was not sharing the work and continued to rebase it off of head (developed via id tfiala@google.com). I switched over to user todd.fiala@gmail.com in the middle, and once I went to github, I did merges rather than rebasing so I could share with others. llvm-svn: 212069
* Change the way the m_trap_handlers Platform base class ivar is initialized;Jason Molenda2014-02-131-0/+3
| | | | | | | | 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
* Rename Platform::GetFile (3-arg version) to GetFileWithUUIDSteve Pucci2014-01-171-2/+2
| | | | | | | | | | | 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
* <rdar://problem/13854277>Greg Clayton2013-05-101-17/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | <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
* Platforms can now auto-select themselves if you specify a full target triple ↵Greg Clayton2012-03-201-1/+1
| | | | | | | | 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
* Enabled the PlatformLinux and PlatforFreeBSD on MacOSX so they can be usedGreg Clayton2012-02-271-1/+2
| | | | | | | | | | | | and also so we don't break them with our code changes. The _only_ plug-ins that should be #ifdef'ed out and not compiled in LLDB are those that only work when running natively on the host system. This fixed bot the PlatformLinux and PlatformFreeBSD build breakages that were due to ModuleSpec changes. llvm-svn: 151539
* This patch combines common code from Linux and FreeBSD intoJohnny Chen2012-01-051-0/+1
| | | | | | | | | | a new POSIX platform. It also contains fixes for 64bit FreeBSD. The patch is based on changes by Mark Peek <mp@FreeBSD.org> and "K. Macy" <kmacy@freebsd.org> in their github repo located at https://github.com/fbsd/lldb. llvm-svn: 147609
* Patch from Dawn that fixes up linux debugging and a first passs at an Greg Clayton2011-11-291-4/+10
| | | | | | implementation of the linux platform. llvm-svn: 145433
* Now the linux platform lets it be known that it can't launch processes forGreg Clayton2011-11-281-0/+6
| | | | | | debugging. llvm-svn: 145221
* Update PlatformLinux::Attach signature.Peter Collingbourne2011-11-211-2/+2
| | | | llvm-svn: 145020
* This patch add a "fake" attach waiting for a real implementation andJohnny Chen2011-05-131-1/+5
| | | | | | | | | | | | | | | | solve the build break due to the lack of this method. It also propose a solution to the API changes in RegisterContext. I upgraded also the the python version in the makefile. My linux installation has python2.7 and AFAIK also the latest ubuntu has this version of python so maybe is worth upgrading. Patch by Marco Minutoli <mminutoli@gmail.com> [Note: I had to hand merge in the diffs since patch thinks it is a corrupt patch.] llvm-svn: 131313
* linux: remove ProcessLinux::FindProcessesStephen Wilson2011-04-071-4/+0
| | | | | | | | | | This method only needs to be overridden in the remote debugging case, the base class handles the host case. Since we do not do remote debugging on Linux yet and there is a typo that causes a build issue, just remove this method for now. llvm-svn: 129069
* Update the linux platform to use the new Host::FindProcesses functionality.Greg Clayton2011-04-061-3/+2
| | | | llvm-svn: 129018
* linux: minor updates to account for recent namespace changesStephen Wilson2011-03-261-2/+3
| | | | llvm-svn: 128313
* linux: PlatformLinux improvementsStephen Wilson2011-03-231-4/+24
| | | | | | | Add a few missing virtual methods to PlatformLinux and have it register itself with PluginManager. llvm-svn: 128128
* LLDB now has "Platform" plug-ins. Platform plug-ins are plug-ins that provideGreg Clayton2011-03-081-0/+89
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