summaryrefslogtreecommitdiffstats
path: root/lldb/source/Target
Commit message (Collapse)AuthorAgeFilesLines
...
* Move more functionality from the LanguageRuntimes to the Languages.Jim Ingham2015-09-022-646/+0
| | | | llvm-svn: 246616
* Add a Language::ForAllLanguages helper functionEnrico Granata2015-09-021-0/+10
| | | | llvm-svn: 246614
* Move things from the LanguageRuntime that obviously belong in the new ↵Jim Ingham2015-09-022-140/+141
| | | | | | Language plugin instead. llvm-svn: 246611
* Have the Process hold a weak_ptr to the Target.Zachary Turner2015-09-012-50/+50
| | | | llvm-svn: 246578
* Add support for language plugins to provide data formatters (second attempt)Enrico Granata2015-09-011-0/+6
| | | | | | | | | | | | | | | | | Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246568
* Make ProcessGDBRemote get a //copy// of platform Unix signals.Chaoren Lin2015-09-011-1/+1
| | | | | | | | | | | | Summary: Update to http://reviews.llvm.org/rL243618. Reviewers: jaydeep, clayborg Subscribers: labath, tberghammer, lldb-commits Differential Revision: http://reviews.llvm.org/D12420 llvm-svn: 246557
* Revert "Add support for language plugins to provide data formatters"Pavel Labath2015-09-011-6/+0
| | | | | | This reverts r246515 (and related cmake fixes) as it breaks all libcxx tests. llvm-svn: 246536
* Add support for language plugins to provide data formattersEnrico Granata2015-09-011-0/+6
| | | | | | | | | | | | | | | | | Historically, data formatters all exist in a global repository (the category map) On top of that, some formatters can be "hardcoded" when the conditions under which they apply are not expressible as a typename (or typename regex) This change paves the way to move formatters into per-language buckets such that the C++ plugin is responsible for ownership of the C++ formatters, and so on The advantages of this are: a) language formatters only get created when they might apply b) formatters for a language are clearly owned by the matching language plugin The current model is one of static instantiation, that is a language knows the full set of formatters it vends and that is only asked-for once, and then handed off to the FormatManager In a future revision it might be interesting to add similar ability to the language runtimes, and monitor for certain shared library events to add even more library-specific formatters No formatters are moved as part of this change, so practically speaking this is NFC llvm-svn: 246515
* Include <mutex>Enrico Granata2015-08-271-0/+1
| | | | llvm-svn: 246222
* Added a missing file to the CMakeListsEnrico Granata2015-08-271-0/+1
| | | | llvm-svn: 246216
* Add a new type of plugin: Language pluginEnrico Granata2015-08-271-0/+101
| | | | | | | | | | The Language plugin is menat to answer language-specific questions that are not bound to the existence of a process. Those are still the domain of the LanguageRuntime plugin The Language plugin will, instead, answer questions such as providing language-specific data formatters or expression evaluation At the moment, the interface is hollowed out, and empty do-nothing plugins have been setup for ObjC, C++ and ObjC++ llvm-svn: 246212
* Add functionality to the platforms to figure out the proper name for a ↵Enrico Granata2015-08-271-0/+6
| | | | | | | | | | | | | | | | 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
* Major DWARF cleanup.Greg Clayton2015-08-261-2/+2
| | | | | | | | | | Added a new class called DWARFDIE that contains a DWARFCompileUnit and DWARFDebugInfoEntry so that these items always stay together. There were many places where we just handed out DWARFDebugInfoEntry pointers and then use them with a compile unit that may or may not be the correct one. Clients outside of DWARFCompileUnit and DWARFDebugInfoEntry should all be dealing with DWARFDIE instances instead of playing with DWARFCompileUnit/DWARFDebugInfoEntry pairs manually. This paves to the way for some modifications that are coming for DWO. llvm-svn: 246100
* [MIPS] Avoid breakpoint in delay slotBhushan D. Attarde2015-08-261-0/+170
| | | | | | | | | | | | | | SUMMARY: This patch implements Target::GetBreakableLoadAddress() method that takes an address and checks for any reason there is a better address than this to put a breakpoint on. If there is then return that address. MIPS uses this method to avoid breakpoint in delay slot. Reviewers: clayborg, jingham Subscribers: jingham, mohit.bhakkad, sagar, jaydeep, nitesh.jain, lldb-commits Differential Revision: http://http://reviews.llvm.org/D12184 llvm-svn: 246015
* Final bit of type system cleanup that abstracts declaration contexts into ↵Greg Clayton2015-08-245-14/+14
| | | | | | | | | | | | | | | | | | | | lldb_private::CompilerDeclContext and renames ClangType to CompilerType in many accessors and functions. Create a new "lldb_private::CompilerDeclContext" class that will replace all direct uses of "clang::DeclContext" when used in compiler agnostic code, yet still allow for conversion to clang::DeclContext subclasses by clang specific code. This completes the abstraction of type parsing by removing all "clang::" references from the SymbolFileDWARF. The new "lldb_private::CompilerDeclContext" class abstracts decl contexts found in compiler type systems so they can be used in internal API calls. The TypeSystem is required to support CompilerDeclContexts with new pure virtual functions that start with "DeclContext" in the member function names. Converted all code that used lldb_private::ClangNamespaceDecl over to use the new CompilerDeclContext class and removed the ClangNamespaceDecl.cpp and ClangNamespaceDecl.h files. Removed direct use of clang APIs from SBType and now use the abstract type systems to correctly explore types. Bulk renames for things that used to return a ClangASTType which is now CompilerType: "Type::GetClangFullType()" to "Type::GetFullCompilerType()" "Type::GetClangLayoutType()" to "Type::GetLayoutCompilerType()" "Type::GetClangForwardType()" to "Type::GetForwardCompilerType()" "Value::GetClangType()" to "Value::GetCompilerType()" "Value::SetClangType (const CompilerType &)" to "Value::SetCompilerType (const CompilerType &)" "ValueObject::GetClangType ()" to "ValueObject::GetCompilerType()" many more renames that are similar. llvm-svn: 245905
* Fix resolution conflict between global and class static variables in C++Paul Herman2015-08-181-1/+1
| | | | llvm-svn: 245381
* A messy bit of cleanup: Move towards more descriptive namesJason Molenda2015-08-151-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | for eh_frame and stabs register numberings. This is not complete but it's a step in the right direction. It's almost entirely mechanical. lldb informally uses "gcc register numbering" to mean eh_frame. Why? Probably because there's a notorious bug with gcc on i386 darwin where the register numbers in eh_frame were incorrect. In all other cases, eh_frame register numbering is identical to dwarf. lldb informally uses "gdb register numbering" to mean stabs. There are no official definitions of stabs register numbers for different architectures, so the implementations of gdb and gcc are the de facto reference source. There were some incorrect uses of these register number types in lldb already. I fixed the ones that I saw as I made this change. This commit changes all references to "gcc" and "gdb" register numbers in lldb to "eh_frame" and "stabs" to make it clear what is actually being represented. lldb cannot parse the stabs debug format, and given that no one is using stabs any more, it is unlikely that it ever will. A more comprehensive cleanup would remove the stabs register numbers altogether - it's unnecessary cruft / complication to all of our register structures. In ProcessGDBRemote, when we get register definitions from the gdb-remote stub, we expect to see "gcc:" (qRegisterInfo) or "gcc_regnum" (qXfer:features:read: packet to get xml payload). This patch changes ProcessGDBRemote to also accept "ehframe:" and "ehframe_regnum" from these remotes. I did not change GDBRemoteCommunicationServerLLGS or debugserver to send these new packets. I don't know what kind of interoperability constraints we might be working under. At some point in the future we should transition to using the more descriptive names. Throughout lldb we're still using enum names like "gcc_r0" and "gdb_r0", for eh_frame and stabs register numberings. These should be cleaned up eventually too. The sources link cleanly on macosx native with xcode build. I don't think we'll see problems on other platforms but please let me know if I broke anyone. llvm-svn: 245141
* I was assuming that when a bit of inlined code was followed by code from the ↵Jim Ingham2015-08-141-4/+8
| | | | | | | | inlining site, it was going to execute to the inlining site code, but apparently that's not always true. So we need to be a bit more careful getting past the inlining, and use a StepOverRange plan not a RunToAddress plan. <rdar://problem/22191804> llvm-svn: 244999
* [LLDB][MIPS] Handle false positives for MIPS hardware watchpointsJaydeep Patil2015-08-131-4/+21
| | | | | | | | | | | | | | | | SUMMARY: Last 3bits of the watchpoint address are masked by the kernel. For example, n is at 0x120010d00 and m is 0x120010d04. When a watchpoint is set at m, then watch exception is generated even when n is read/written. To handle this case, instruction at PC is emulated to find the base address of the load/store instruction. This address is then appended to the description of the stop-info packet. Client then reads this information to check whether the user has set a watchpoint on this address. Reviewers: jingham, clayborg Subscribers: nitesh.jain, mohit.bhakkad, sagar, bhushan and lldb-commits Differential Revision: http://reviews.llvm.org/D11672 llvm-svn: 244864
* Download symbol file for .oat files on androidTamas Berghammer2015-08-121-2/+12
| | | | | | | | | | | | | On android .oat files (compiled java code) don't have symbol information but on SDK 23+ it can be generated by the oatdump tool (based on the dex information). This CL adds logic to download this information and store it in the module cache. Differential revision: http://reviews.llvm.org/D11936 llvm-svn: 244738
* ClangASTType is now CompilerType.Greg Clayton2015-08-117-14/+14
| | | | | | This is more preparation for multiple different kinds of types from different compilers (clang, Pascal, Go, RenderScript, Swift, etc). llvm-svn: 244689
* First step in getting LLDB ready to support multiple different type systems.Greg Clayton2015-08-111-2/+2
| | | | | | | | This is the work done by Ryan Brown from http://reviews.llvm.org/D8712 that makes a TypeSystem class and abstracts types to be able to use a type system. All tests pass on MacOSX and passed on linux the last time this was submitted. llvm-svn: 244679
* Feedback from Jim: Change the "optimized code" warning to be entirelyJason Molenda2015-08-102-8/+16
| | | | | | | | | | | | contained within Process so that we won't be duplicating the warning message if other parts of the code want to issue the message. Change Process::PrintWarning to be a protected method - the public method will be the PrintWarningOptimization et al. Also, Have Thread::FunctionOptimizationWarning shortcut out if the warnings have been disabled so that we don't (potentially) compute parts of the SymbolContext unnecessarily. llvm-svn: 244436
* Change the warning message about optimization to be printed onceJason Molenda2015-08-061-4/+5
| | | | | | | | | | | | | per Module instead of once per CompileUnit, and print the module name. A module may have a mix of compile units built with optimization and compile units built without optimization -- the warning won't be printed until the user selects a stack frame of a function that was built with optimization. And as before, it will only be printed once per module per debug session. <rdar://problem/19281172> llvm-svn: 244281
* Second part of indicating when the user is stopped in optimized code.Jason Molenda2015-08-062-1/+83
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The first part was in r243508 -- the extent of the UI changes in that patchset was to add "[opt]" to the frame-format when a stack frame was built with optimized code. In this change, when a stack frame built with optimization is selected, a message will be printed to the async output channel -- opt1.c was compiled with optimization - stepping may behave oddly; variables may not be available. The warning will be only be printed once per source file in a debug session. These warnings may be disabled by settings set target.process.optimization-warnings false Internally, a new Process::PrintWarning() method has been added for warnings that we want to print only once to the user. It takes a type of warning (currently only eWarningsOptimization) and an object pointer (CompileUnit*) - the warning will only be printed once for a given object pointer value. This is a bit of a prototype of this change - I think we will be tweaking it more in the future. But I wanted to land this and see how it goes. Advanced users will find these warnings unnecessary noise and will quickly disable them - but anyone who maintains a debugger knows that debugging optimized code, without realizing it, is a constant source of confusion and frustation for more typical debugger users. I imagine there will be more of these "warn once per whatever" style warnings that we will want to add in the future and we'll need to come up with a better way for enabling/disabling them. But I'm not srue what form that warning settings should take and I didn't want to code up something that we regret later, so for now I just added another process setting for this one warning. <rdar://problem/19281172> llvm-svn: 244190
* Fix help message for target.language setting.Dawn Perchik2015-07-301-1/+1
| | | | llvm-svn: 243697
* Add a function to make a mutex-protected copy of a breakpoint site'sJim Ingham2015-07-291-7/+6
| | | | | | | | | | owners list, so the StopInfo machinery can get the list of owners without some other thread being able to mess up the list by deleting/disabline one of its locations in the process of doing so. <rdar://problem/18685197> llvm-svn: 243541
* Add some initial logging for when lldb is searching for binaries,Jason Molenda2015-07-251-0/+5
| | | | | | | | | dSYMs, or reading binaries out of memory to the 'Host' log channel. There's more to be done here, both for Mac and for other platforms, but the initial set of new loggings are useful enough to check in at this point. llvm-svn: 243200
* Improve C++ function name handling and step-in avoid regerxp handlingTamas Berghammer2015-07-242-11/+8
| | | | | | | | | | | | | | | | | | | If the function is a template then the return type is part of the function name. This CL fixes the parsing of these function names in the case when the return type contains ':'. The name of free functions in C++ don't have context part. Fix the logic geting the function name without arguments out from a full function name to handle this case. Change the handling of step-in-avoid-regexp to match the value against the function name without it's arguments and return value. This is required because the default regex ("^std::") would match any template function returning an std object. Fifferential revision: http://reviews.llvm.org/D11461 llvm-svn: 243099
* Add UNUSED_IF_ASSERT_DISABLED and apply it.Bruce Mitchener2015-07-241-1/+1
| | | | | | | | | | | | | | | Summary: This replaces (void)x; usages where they x was subsequently involved in an assertion with this macro to make the intent more clear. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11451 llvm-svn: 243074
* Most thread plans don't handle eStopReasonInstrumentation stop reasons,Jim Ingham2015-07-235-139/+133
| | | | | | | | | | but that wasn't added to the list of reasons they don't explain. That would mean we keep stepping after hitting the AsanDie breakpoint rather than stopping when the Asan event occurred. <rdar://problem/21925479> llvm-svn: 243035
* Fix warnings.Bruce Mitchener2015-07-221-0/+1
| | | | | | | | | | Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11404 llvm-svn: 242913
* Fix warnings found by -Wextra-semiPavel Labath2015-07-221-4/+1
| | | | | | patch by Eugene Zelenko. llvm-svn: 242875
* Fix typos.Bruce Mitchener2015-07-221-2/+2
| | | | | | | | | | | | Summary: Fix a bunch of typos. Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D11386 llvm-svn: 242856
* Add support for specifying a language to use when parsing breakpoints.Dawn Perchik2015-07-212-1/+66
| | | | | | | | | | | | | | | | | | | | Target and breakpoints options were added: breakpoint set --language lang --name func settings set target.language pascal These specify the Language to use when interpreting the breakpoint's expression (note: currently only implemented for breakpoints on identifiers). If the breakpoint language is not set, the target.language setting is used. This support is required by Pascal, for example, to set breakpoint at 'ns.foo' for function 'foo' in namespace 'ns'. Tests on the language were also added to Module::PrepareForFunctionNameLookup for efficiency. Reviewed by: clayborg Subscribers: jingham, lldb-commits Differential Revision: http://reviews.llvm.org/D11119 llvm-svn: 242844
* More packet performance improvements. Greg Clayton2015-07-172-1/+15
| | | | | | | | Changed the "jthreads" key/value in the stop reply packets to be "jstopinfo". This JSON only contains threads with valid stop reasons and allows us not to have to ask about other threads via qThreadStopInfo when we are stepping. The "jstopinfo" only gets sent if there are more than one thread since the stop reply packet contains all the info needed for a single thread. Added a Process::WillPublicStop() in case process subclasses want to do any extra gathering for public stops. For ProcessGDBRemote, we end up sending a jThreadsInfo packet to gather all expedited registers, expedited memory and MacOSX queue information. We only do this for public stops to minimize the packets we send when we have multiple private stops. Multiple private stops happen when a source level single step, step into or step out run the process multiple times while implementing the stepping, and none of these private stops make it out to the UI via notifications because they are private stops. llvm-svn: 242593
* Fix compiler warning in ThreadPlanStepRangePavel Labath2015-07-161-1/+1
| | | | llvm-svn: 242403
* Small fix to ThreadPlanStepRange::DumpRanges to loggingJason Molenda2015-07-141-1/+1
| | | | | | output when stepping through multiple ranges. llvm-svn: 242243
* Expression evaluation, a new ThreadPlanCallFunctionUsingABI for executing a ↵Ewan Crawford2015-07-144-12/+140
| | | | | | | | | | | | | | | | | | | | function call on target via register manipulation For Hexagon we want to be able to call functions during debugging, however currently lldb only supports this when there is JIT support. Although emulation using IR interpretation is an alternative, it is currently limited in that it can't make function calls. In this patch we have extended the IR interpreter so that it can execute a function call on the target using register manipulation. To do this we need to handle the Call IR instruction, passing arguments to a new thread plan and collecting any return values to pass back into the IR interpreter. The new thread plan is needed to call an alternative ABI interface of "ABI::PerpareTrivialCall()", allowing more detailed information about arguments and return values. Reviewers: jingham, spyffe Subscribers: emaste, lldb-commits, ted, ADodds, deepak2427 Differential Revision: http://reviews.llvm.org/D9404 llvm-svn: 242137
* Refactor Unix signals.Chaoren Lin2015-07-144-18/+88
| | | | | | | | | | | | | | | | | | Summary: - Consolidate Unix signals selection in UnixSignals. - Make Unix signals available from platform. - Add jSignalsInfo packet to retrieve Unix signals from remote platform. - Get a copy of the platform signal for each remote process. - Update SB API for signals. - Update signal utility in test suite. Reviewers: ovyalov, clayborg Subscribers: chaoren, jingham, labath, emaste, tberghammer, lldb-commits Differential Revision: http://reviews.llvm.org/D11094 llvm-svn: 242101
* Don't try to make a pseudo terminal if we are launching in a separate ↵Greg Clayton2015-07-101-0/+7
| | | | | | terminal, it causes a deadlock when debugging because we create a PTY and yet it isn't hooked up to anything on the slave side. llvm-svn: 241919
* Avoid going through Platform when creating a NativeProcessProtocol instancePavel Labath2015-07-091-21/+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
* Make many mangled functions that might demangle a name be allowed to specify ↵Greg Clayton2015-07-081-1/+1
| | | | | | a language to use in order to soon support Pascal and Java demangling. Dawn Perchik will take care of making this so. llvm-svn: 241751
* Revert r241672, which breaks the OS X build by introducing a dependency onSean Callanan2015-07-081-0/+21
| | | | | | | | | | | | | | | | 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-21/+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
* Don't select a thread that stopped for a signal that wasJim Ingham2015-07-081-1/+14
| | | | | | | | | not set to stop - there must be some other thread that stopped for a more interesting reason. <rdar://problem/19943567> llvm-svn: 241650
* Fix indentation.Greg Clayton2015-07-011-2/+2
| | | | llvm-svn: 241209
* [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
* Resubmitting 240466 after fixing the linux test suite failures.Greg Clayton2015-06-253-40/+108
| | | | | | | | | | | | | | | A few extras were fixed - Symbol::GetAddress() now returns an Address object, not a reference. There were places where people were accessing the address of a symbol when the symbol's value wasn't an address symbol. On MacOSX, undefined symbols have a value zero and some places where using the symbol's address and getting an absolute address of zero (since an Address object with no section and an m_offset whose value isn't LLDB_INVALID_ADDRESS is considered an absolute address). So fixing this required some changes to make sure people were getting what they expected. - Since some places want to access the address as a reference, I added a few new functions to symbol: Address &Symbol::GetAddressRef(); const Address &Symbol::GetAddressRef() const; Linux test suite passes just fine now. <rdar://problem/21494354> llvm-svn: 240702
* Proper handling of QNonStop packet response.Ewan Crawford2015-06-241-0/+7
| | | | | | Turn non-stop mode off if reply to QNonStop packet isn't an OK. llvm-svn: 240546
OpenPOWER on IntegriCloud