summaryrefslogtreecommitdiffstats
path: root/lldb/source/Target
Commit message (Collapse)AuthorAgeFilesLines
* Add the ability to limit "source regexp" breakpoints to a particular functionJim Ingham2016-04-281-1/+6
| | | | | | | | | | | | within a source file. This isn't done, I need to make the name match smarter (right now it requires an exact match which is annoying for methods of a class in a namespace. Also, though we use it in tests all over the place, it doesn't look like we have a test for Source Regexp breakpoints by themselves, I'll add that in a follow-on patch. llvm-svn: 267834
* When building the list of variables we're going to write "using ↵Jim Ingham2016-04-261-2/+5
| | | | | | | | | $_lldb_local_vars" statements for, be sure not to include variables that have no locations. We wouldn't be able to realize them, and that will cause all expressions to fail. llvm-svn: 267500
* Fix StackFrame::GetVariables(...) function that was broken by 261858 when ↵Greg Clayton2016-04-251-1/+1
| | | | | | | | lambda functions were added to Block::AppendBlockVariables(). The Stackframe::GetVariables(...) function should get all variables regardless if they are in scope. This wasn't caught by the test suite so I added a test for it. llvm-svn: 267478
* Corrected wording of REPL not available messaging (contained a repeated word ↵Kate Stone2016-04-211-1/+1
| | | | | | and lacked clarity.) llvm-svn: 266941
* Revert "LLDB: Fixed two race conditions when stopping private state thread"Pavel Labath2016-04-191-4/+8
| | | | | | This reverts commit r266733 as it causes a number of failures on linux buildbots. llvm-svn: 266736
* LLDB: Fixed two race conditions when stopping private state threadMarianne Mailhot-Sarrasin2016-04-191-8/+4
| | | | | | | | | | | | | | When stopping the private state thread, there was a race condition between the time the thread exits (resetting the HostThread object) and the time a Join was attempted, especially in the case of a timeout. The previous workaround of copying the HostThread object is not enough, since on a Reset the internal thread stuff gets nulled out regardless of which HostThread object actually has Reset called on it, resulting in an attempt to dereference a null pointer on the subsequent call to Join from the copy as well. Additionally, there was a race between the detach (called when stopping the process) and the stop itself, causing the stop to time out because it was waiting for the private state thread to see the stop state, but it had exited immediately after entering the detached state. Patch by cameron314 Differential Revision: http://reviews.llvm.org/D19122 llvm-svn: 266733
* Miscellaneous fixes for big-endian systemsUlrich Weigand2016-04-141-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch fixes a bunch of issues that show up on big-endian systems: - The gnu_libstdcpp.py script doesn't follow the way libstdc++ encodes bit vectors: it should identify the enclosing *word* and then access the appropriate bit within that word. Instead, the script simply operates on bytes. This gives the same result on little-endian systems, but not on big-endian. - lldb_private::formatters::WCharSummaryProvider always assumes wchar_t is UTF16, even though it could also be UTF8 or UTF32. This is mostly not an issue on little-endian systems, but immediately fails on BE. Fixed by checking the size of wchar_t like WCharStringSummaryProvider already does. - ClangASTContext::GetChildCompilerTypeAtIndex uses uint32_t to access the virtual base offset stored in the vtable, even though the size of this field matches the target pointer size according to the C++ ABI. Again, this is mostly not visible on LE, but fails on BE. - Process::ReadStringFromMemory uses strncmp to search for a terminator consisting of multiple zero bytes. This doesn't work since strncmp will stop already at the first zero byte. Use memcmp instead. Differential Revision: http://reviews.llvm.org/D18983 llvm-svn: 266313
* Support Linux on SystemZ as platformUlrich Weigand2016-04-142-0/+9
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for Linux on SystemZ: - A new ArchSpec value of eCore_s390x_generic - A new directory Plugins/ABI/SysV-s390x providing an ABI implementation - Register context support - Native Linux support including watchpoint support - ELF core file support - Misc. support throughout the code base (e.g. breakpoint opcodes) - Test case updates to support the platform This should provide complete support for debugging the SystemZ platform. Not yet supported are optional features like transaction support (zEC12) or SIMD vector support (z13). There is no instruction emulation, since our ABI requires that all code provide correct DWARF CFI at all PC locations in .eh_frame to support unwinding (i.e. -fasynchronous-unwind-tables is on by default). The implementation follows existing platforms in a mostly straightforward manner. A couple of things that are different: - We do not use PTRACE_PEEKUSER / PTRACE_POKEUSER to access single registers, since some registers (access register) reside at offsets in the user area that are multiples of 4, but the PTRACE_PEEKUSER interface only allows accessing aligned 8-byte blocks in the user area. Instead, we use a s390 specific ptrace interface PTRACE_PEEKUSR_AREA / PTRACE_POKEUSR_AREA that allows accessing a whole block of the user area in one go, so in effect allowing to treat parts of the user area as register sets. - SystemZ hardware does not provide any means to implement read watchpoints, only write watchpoints. In fact, we can only support a *single* write watchpoint (but this can span a range of arbitrary size). In LLDB this means we support only a single watchpoint. I've set all test cases that require read watchpoints (or multiple watchpoints) to expected failure on the platform. [ Note that there were two test cases that install a read/write watchpoint even though they nowhere rely on the "read" property. I've changed those to simply use plain write watchpoints. ] Differential Revision: http://reviews.llvm.org/D18978 llvm-svn: 266308
* Add new ABI callback to provide fallback unwind register locationsUlrich Weigand2016-04-141-0/+24
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the UnwindPlan did not identify how to unwind the stack pointer register, LLDB currently assumes it can determine to caller's SP from the current frame's CFA. This is true on most platforms where CFA is by definition equal to the incoming SP at function entry. However, on the s390x target, we instead define the CFA to equal the incoming SP plus an offset of 160 bytes. This is because our ABI defines that the caller has to provide a register save area of size 160 bytes. This area is allocated by the caller, but is considered part of the callee's stack frame, and therefore the CFA is defined as pointing to the top of this area. In order to make this work on s390x, this patch introduces a new ABI callback GetFallbackRegisterLocation that provides platform- specific fallback register locations for unwinding. The existing code to handle SP unwinding as well as volatile registers is moved into the default implementation of that ABI callback, to allow targets where that implementation is incorrect to override it. This patch in itself is a no-op for all existing platforms. But it is a pre-requisite for adding s390x support. Differential Revision: http://reviews.llvm.org/D18977 llvm-svn: 266307
* Provide more information in ThreadSanitizer's JSON data. Move remaining ↵Kuba Brecka2016-04-101-0/+6
| | | | | | TSan logic from SBThread to InstrumentationRuntime plugin. llvm-svn: 265905
* In GDBRemoteCommunicationClient::GetHostInfo, don't set theJason Molenda2016-04-071-1/+1
| | | | | | | | | | | | | | | | | | os to "ios" or "macosx" if it is unspecified. For environments where there genuinely is no os, we don't want to errantly convert that to ios/macosx, e.g. bare board debugging. Change PlatformRemoteiOS, PlatformRemoteAppleWatch, and PlatformRemoteAppleTV to not create themselves if we have an unspecified OS. Same problem - these are not appropriate platforms for bare board debugging environments. Have Process::Attach's logging take place if either process or target logging is enabled. <rdar://problem/25592378> llvm-svn: 265732
* Make sure to update Target arch if environment changedStephane Sezer2016-04-051-1/+1
| | | | | | | | | | | | | | Summary: Fixes "target list" for non-android linux platforms (ie gnu, gnueabi) Reviewers: jasonmolenda, tfiala, clayborg, tberghammer Subscribers: tberghammer, danalbert, lldb-commits, sas Differential Revision: http://reviews.llvm.org/D18631 Change by Francis Ricci <fjricci@fb.com> llvm-svn: 265419
* Fix a bug in linux core file handlingPavel Labath2016-04-051-1/+13
| | | | | | | | | | | | | | | | | | | Summary: There was a bug in linux core file handling, where if there was a running process with the same process id as the id in the core file, the core file debugging would fail, as we would pull some pieces of information (ProcessInfo structure) from the running process instead of the core file. I fix this by routing the ProcessInfo requests through the Process class and overriding it in ProcessElfCore to return correct data. A (slightly convoluted) test is included. Reviewers: clayborg, zturner Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D18697 llvm-svn: 265391
* Improve the way LLDB escapes arguments before passing them to the shellEnrico Granata2016-04-042-1/+7
| | | | | | | | | | | | | Teach LLDB that different shells have different characters they are sensitive to, and use that knowledge to do shell-aware escaping This helps solve a class of problems on OS X where LLDB would try to launch via sh, and run into problems if the command line being passed to the inferior contained such special markers (hint: the shell would error out and we'd fail to launch) This makes those launch scenarios work transparently via shell expansion Slightly improve the error message when this kind of failure occurs to at least suggest that the user try going through 'process launch' directly Fixes rdar://problem/22749408 llvm-svn: 265357
* Figure out what the fixed expression is, and print it. Added another target ↵Jim Ingham2016-03-291-2/+14
| | | | | | | | | | | | | setting to quietly apply fixits for those who really trust clang's fixits. Also, moved the retry into ClangUserExpression::Evaluate, where I can make a whole new ClangUserExpression to do the work. Reusing any of the parts of a UserExpression in situ isn't supported at present. <rdar://problem/25351938> llvm-svn: 264793
* Use Clang's FixItHints to correct expressions with "trivial" mistakes (e.g. ↵Jim Ingham2016-03-251-0/+9
| | | | | | | | | | | | | | | "." for "->".) This feature is controlled by an expression command option, a target property and the SBExpressionOptions setting. FixIt's are only applied to UserExpressions, not UtilityFunctions, those you have to get right when you make them. This is just a first stage. At present the fixits are applied silently. The next step is to tell the user about the applied fixit. <rdar://problem/25351938> llvm-svn: 264379
* Make it possible for language plugins to provide additional custom help for ↵Enrico Granata2016-03-241-0/+6
| | | | | | 'type lookup' llvm-svn: 264356
* Unicode support on Win32.Zachary Turner2016-03-221-4/+11
| | | | | | | | | | | | | Win32 API calls that are Unicode aware require wide character strings, but LLDB uses UTF8 everywhere. This patch does conversions wherever necessary when passing strings into and out of Win32 API calls. Patch by Cameron Differential Revision: http://reviews.llvm.org/D17107 Reviewed By: zturner, amccarth llvm-svn: 264074
* Add a DiagnosticManager replace error streams in the expression parser.Sean Callanan2016-03-192-39/+49
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We want to do a better job presenting errors that occur when evaluating expressions. Key to this effort is getting away from a model where all errors are spat out onto a stream where the client has to take or leave all of them. To this end, this patch adds a new class, DiagnosticManager, which contains errors produced by the compiler or by LLDB as an expression is created. The DiagnosticManager can dump itself to a log as well as to a string. Clients will (in the future) be able to filter out the errors they're interested in by ID or present subsets of these errors to the user. This patch is not intended to change the *users* of errors - only to thread DiagnosticManagers to all the places where streams are used. I also attempt to standardize our use of errors a bit, removing trailing newlines and making clients omit 'error:', 'warning:' etc. and instead pass the Severity flag. The patch is testsuite-neutral, with modifications to one part of the MI tests because it relied on "error: error:" being erroneously printed. This patch fixes the MI variable handling and the testcase. <rdar://problem/22864976> llvm-svn: 263859
* Only try to load the OS plug-in after a shared library load if we don't ↵Greg Clayton2016-03-151-1/+4
| | | | | | | | already have one. <rdar://problem/24162686> llvm-svn: 263602
* Improve the 'type lookup' command such that it guesses to use the current's ↵Enrico Granata2016-03-151-1/+19
| | | | | | frame language as the one to start searching from. llvm-svn: 263592
* This change introduces a "ExpressionExecutionThread" to the ThreadList. Jim Ingham2016-03-122-0/+41
| | | | | | | | | | | | | | | | | | | Turns out that most of the code that runs expressions (e.g. the ObjC runtime grubber) on behalf of the expression parser was using the currently selected thread. But sometimes, e.g. when we are evaluating breakpoint conditions/commands, we don't select the thread we're running on, we instead set the context for the interpreter, and explicitly pass that to other callers. That wasn't getting communicated to these utility expressions, so they would run on some other thread instead, and that could cause a variety of subtle and hard to reproduce problems. I also went through the commands and cleaned up the use of GetSelectedThread. All those uses should have been trying the thread in the m_exe_ctx belonging to the command object first. It would actually have been pretty hard to get misbehavior in these cases, but for correctness sake it is good to make this usage consistent. <rdar://problem/24978569> llvm-svn: 263326
* Fixed MemoryCache L1 cache flushMarianne Mailhot-Sarrasin2016-03-111-1/+5
| | | | | | | | Use the same method to find the cache line as in Read(). Differential Revision: http://reviews.llvm.org/D18050 llvm-svn: 263233
* Add an "offset" option to "break set -n" and "break set -f -l". Jim Ingham2016-03-091-30/+46
| | | | | | | | | | | | That way you can set offset breakpoints that will move as the function they are contained in moves (which address breakpoints can't do...) I don't align the new address to instruction boundaries yet, so you have to get this right yourself for now. <rdar://problem/13365575> llvm-svn: 263049
* Change over the broadcaster/listener process to hold shared or weak pointersJim Ingham2016-03-075-71/+75
| | | | | | | | | | | | | | to each other. This should remove some infrequent teardown crashes when the listener is not the debugger's listener. Processes now need to take a ListenerSP, not a Listener&. This required changing over the Process plugin class constructors to take a ListenerSP, instead of a Listener&. Other than that there should be no functional change. <rdar://problem/24580184> CrashTracer: [USER] Xcode at …ework: lldb_private::Listener::BroadcasterWillDestruct + 39 llvm-svn: 262863
* Add reverse file remapping for breakpoint setTamas Berghammer2016-03-042-3/+31
| | | | | | | | | | | | | | LLDB can remap a source file to a new directory based on the "target.sorce-map" to handle the usecase when the source code moved between the compliation and the debugging. Previously the remapping was only used to display the content of the file. This CL fixes the scenario when a breakpoint is set based on the new an absolute path with adding an inverse remapping step before looking up the breakpoint location. Differential revision: http://reviews.llvm.org/D17848 llvm-svn: 262711
* Fix MSVC build failure in source/Target/Process.cpp.Eugene Zelenko2016-03-011-1/+1
| | | | | | Will be good idea to introduce macro/constexpr for NULL thread_result_t. llvm-svn: 262287
* Fix Clang-tidy modernize-use-nullptr warnings in some files in ↵Eugene Zelenko2016-03-011-194/+182
| | | | | | source/Target/Process.cpp; other minor fixes. llvm-svn: 262281
* Make LLDB safer to use with respect to the global destructor chain.Greg Clayton2016-02-263-12/+15
| | | | llvm-svn: 262090
* Make sure to #include <atomic> for the std::atomic<bool> that was recently ↵Greg Clayton2016-02-261-0/+1
| | | | | | added. llvm-svn: 262055
* Make sure the Target, Process and Thread GetGlobalProperties() static ↵Greg Clayton2016-02-263-8/+18
| | | | | | | | methods are thread safe. <rdar://problem/22595283> llvm-svn: 262053
* The IOHandlerProcessSTDIO is the _only_ IOHandler that gets pushed and ↵Greg Clayton2016-02-261-3/+22
| | | | | | | | | | | | | | popped from functions that are run due to something that is NOT input from the user. All other IOHandler objects result from input from the user. An issue rose up where if a command caused the process to resume and stop and process state changed, where state changed Event objects were broadcast, it would cause the IOHandlerProcessSTDIO to have its IOHandlerProcessSTDIO::Cancel() function called. This used to always write a byte to the control pipe (IOHandlerProcessSTDIO::m_pipe) even if the IOHandlerProcessSTDIO::Run() was never called. What would happen is: (lldb) command_that_steps_process_thousands_of_times As the "command_that_steps_process_thousands_of_times" could be a python command that resumed the process thousands of times and in doing so the IOHandlerProcessSTDIO would get pushed when the process resumed, and popped when it stoppped, causing the call to IOHandlerProcessSTDIO::Cancel(). Since the IOHandler thread is currently in IOHandlerEditline::Run() for the command interpreter handling the "command_that_steps_process_thousands_of_times" command, IOHandlerProcessSTDIO::Run() would never get called, even though the IOHandlerProcessSTDIO is on the top of the stack. This caused the command pipe to keep getting 1 bytes written each time the IOHandlerProcessSTDIO::Cancel() was called and eventually we will deadlock since the write buffer is full. The fix here is to make sure we are in IOHandlerProcessSTDIO::Run() before we write anything to the command pipe, and just call SetIsDone(true) if we are not. <rdar://problem/22361364> llvm-svn: 262040
* Add mips32 software breakpoints into ↵Aidan Dodds2016-02-261-0/+2
| | | | | | | | | | platform::GetSoftwareBreakpointTrapOpcode(). The software breakpoint definitions for mips32 should have been included in my recent patch that moved the software breakpoint definitions into the base platform class. llvm-svn: 262021
* Add support for DW_OP_push_object_address in dwarf expressionsTamas Berghammer2016-02-261-2/+9
| | | | | | | | | Additionally fix the type of some dwarf expression where we had a confusion between scalar and load address types after a dereference. Differential revision: http://reviews.llvm.org/D17604 llvm-svn: 262014
* Fix all of the unannotated switch cases to annotate the fall through or do ↵Greg Clayton2016-02-261-0/+1
| | | | | | the right thing and break. llvm-svn: 261950
* Handle the case when a variable is only valid in part of the enclosing scopeTamas Berghammer2016-02-251-1/+6
| | | | | | | | | | | DWARF stores this information in the DW_AT_start_scope attribute. This CL add support for this attribute and also changes the functions displaying frame variables to only display the variables currently in scope. Differential revision: http://reviews.llvm.org/D17449 llvm-svn: 261858
* Refactor GetSoftwareBreakpointTrapOpcodeAidan Dodds2016-02-221-0/+103
| | | | | | | | 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
* This patch stops lldb from loading a .lldbinit file from the currentJason Molenda2016-02-191-0/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | working directory by default -- a typical security problem that we need to be more conservative about. It adds a new target setting, target.load-cwd-lldbinit which may be true (always read $cwd/.lldbinit), false (never read $cwd/.lldbinit) or warn (warn if there is a $cwd/.lldbinit and don't read it). The default is set to warn. If this is met with unhappiness, we can look at changing the default to true (to match current behavior) on a different platform. This does not affect reading of ~/.lldbinit - that will still be read, as before. If you run lldb in your home directory, it will not warn about the presence of a .lldbinit file there. I had to add two SB API - SBHostOS::GetUserHomeDirectory and SBFileSpec::AppendPathComponent - for the lldb driver code to be able to get the home directory path in an OS neutral manner. The warning text is There is a .lldbinit file in the current directory which is not being read. To silence this warning without sourcing in the local .lldbinit, add the following to the lldbinit file in your home directory: settings set target.load-cwd-lldbinit false To allow lldb to source .lldbinit files in the current working directory, set the value of this variable to true. Only do so if you understand and accept the security risk. <rdar://problem/24199163> llvm-svn: 261280
* Fix Clang-tidy modernize-use-nullptr warnings in some files in ↵Eugene Zelenko2016-02-189-200/+155
| | | | | | source/Target; other minor fixes. llvm-svn: 261242
* Fix Clang-tidy modernize-use-nullptr warnings; other minor fixes.Eugene Zelenko2016-02-1811-253/+170
| | | | llvm-svn: 261179
* Add -Wimplicit-fallthrough command line option to clang inJason Molenda2016-02-162-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | the xcode project file to catch switch statements that have a case that falls through unintentionally. Define LLVM_FALLTHROUGH to indicate instances where a case has code and intends to fall through. This should be in llvm/Support/Compiler.h; Peter Collingbourne originally checked in there (r237766), then reverted (r237941) because he didn't have time to mark up all the 'case' statements that were intended to fall through. I put together a patch to get this back in llvm http://reviews.llvm.org/D17063 but it hasn't been approved in the past week. I added a new lldb-private-defines.h to hold the definition for now. Every place in lldb where there is a comment that the fall-through is intentional, I added LLVM_FALLTHROUGH to silence the warning. I haven't tried to identify whether the fallthrough is a bug or not in the other places. I haven't tried to add this to the cmake option build flags. This warning will only work for clang. This build cleanly (with some new warnings) on macosx with clang under xcodebuild, but if this causes problems for people on other configurations, I'll back it out. llvm-svn: 260930
* Objective-C++ is a kind of C++.Sean Callanan2016-02-121-0/+1
| | | | llvm-svn: 260715
* Make Target::CalculateProcess() return a sensible result.Sean Callanan2016-02-121-1/+1
| | | | | | | | The Calculate* functions in general should not derive any information that isn't implicit, but for Target the process pointer is a member so it's fine to return it for CalculateProcess(). llvm-svn: 260713
* Now that SymbolFileDWARF supports having types in completely separate .pcm ↵Greg Clayton2016-02-101-1/+4
| | | | | | | | | | | | | | file with "-fmodules -gmodules", each SymbolFileDWARF can reference module DWARF info by looking in other DWARF files. Then if you have 1000 .o files that each reference one or more .pcm files in their debug info, a simple Module::FindTypes(...) call can end up searching the same .pcm file over and over and over. Now all internal FindTypes methods in classes (ModuleList, Module, SymbolFile) now take an extra argument: llvm::DenseSet<lldb_private::SymbolFile *> &searched_symbol_files Each time a SymbolFile::FindTypes() is called, it needs to check the searched_symbol_files list to make sure it hasn't already been asked to find the type and return immediately if it has been checked. This will stop circular dependencies from also crashing LLDB during type queries. This has proven to be an issue when debugging large applications on MacOSX that use DWARF in .o files. <rdar://problem/24581488> llvm-svn: 260434
* Per Jim's suggestion, move checks that we're not mixing and matching ↵Enrico Granata2016-02-061-1/+0
| | | | | | | | Debuggers and Commands deeper in the bowels of LLDB NFC llvm-svn: 259972
* Fix an issue where certain CommandObjects (or Options thereof) were being ↵Enrico Granata2016-02-061-0/+4
| | | | | | | | | | created once, bound to a specific CommandInterpreter (and hence a specific Debugger), and then cached for reuse across different Debugger instances Obviously, if the original Debugger goes away, those commands are holding on to now stale memory, which has the potential to cause crashes Fixes rdar://24460882 llvm-svn: 259964
* Fix a little threading thinko in StartPrivateStateThread - don't pass stack ↵Jim Ingham2016-02-041-4/+5
| | | | | | | | | | variables as args to a pthread_create function... <rdar://problem/24485206> llvm-svn: 259738
* Remove a stray ;.Jim Ingham2016-02-031-1/+0
| | | | llvm-svn: 259685
* The SetStopInfo from a Mach Exception was setting the stopJim Ingham2016-02-031-1/+2
| | | | | | | | | | reason to None when we stop due to a trace, then noticed that we were on a breakpoint that was not valid for the current thread. That should actually have set it back to trace. This was pr26441 (<rdar://problem/24470203>) llvm-svn: 259684
* Fix a thinko in StackFrame::GetInScopeVariableList.Siva Chandra2016-02-021-1/+1
| | | | | | | | | | Reviewers: clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D16745 llvm-svn: 259607
OpenPOWER on IntegriCloud