aboutsummaryrefslogtreecommitdiff
path: root/lldb/source/Target/ThreadPlanCallFunction.cpp
AgeCommit message (Collapse)AuthorFilesLines
2025-02-28[lldb] Restore register state if PrepareTrivialCall fails (#129038)David Spickett1-1/+12
Fixes #124269 PrepareTrivalCall always had the possibility of failing, but given that it only wrote to general purpose registers, if it did, you had bigger problems. When it failed, we did not mark the thread plan valid and when it was torn down we didn't try to restore the register state. This meant that if you tried to continue, the program was unlikely to work. When I added AArch64 GCS support, I needed to handle the situation where the GCS pointer points to unmapped memory and we fail to write the extra entry we need. So I added code to restore the gcspr_el0 register specifically if this happened, and ordered the operations so that we tried this first. In this change I've made the teardown of an invalid thread plan restore the register state if one was saved. It may be there isn't one if ConstructorSetup fails, but this is ok because that function does not modify anything. Now that we're doing that, I don't need the GCS specific code anymore, and all thread plans are protected from this in the rare event something does fail. Testing is done by the existing GCS test case that points the gcspr into unmapped memory which causes PrepareTrivialCall to fail. I tried adding a simulated test using a mock gdb server. This was not possible because they all use DynamicLoaderStatic which disables all JIT features.
2023-11-30[lldb] [mostly NFC] Large WP foundation: WatchpointResources (#68845)Jason Molenda1-2/+2
This patch is rearranging code a bit to add WatchpointResources to Process. A WatchpointResource is meant to represent a hardware watchpoint register in the inferior process. It has an address, a size, a type, and a list of Watchpoints that are using this WatchpointResource. This current patch doesn't add any of the features of WatchpointResources that make them interesting -- a user asking to watch a 24 byte object could watch this with three 8 byte WatchpointResources. Or a Watchpoint on 1 byte at 0x1002 and a second watchpoint on 1 byte at 0x1003, these must both be served by a single WatchpointResource on that doubleword at 0x1000 on a 64-bit target, if two hardware watchpoint registers were used to track these separately, one of them may not be hit. Or if you have one Watchpoint on a variable with a condition set, and another Watchpoint on that same variable with a command defined or different condition, or ignorecount, both of those Watchpoints need to evaluate their criteria/commands when their WatchpointResource has been hit. There's a bit of code movement to rearrange things in the direction I'll need for implementing this feature, so I want to start with reviewing & landing this mostly NFC patch and we can focus on the algorithmic choices about how WatchpointResources are shared and handled as they're triggeed, separately. This patch also stops printing "Watchpoint <n> hit: old value: <x>, new vlaue: <y>" for Read watchpoints. I could make an argument for print "Watchpoint <n> hit: current value <x>" but the current output doesn't make any sense, and the user can print the value if they are particularly interested. Read watchpoints are used primarily to understand what code is reading a variable. This patch adds more fallbacks for how to print the objects being watched if we have types, instead of assuming they are all integral values, so a struct will print its elements. As large watchpoints are added, we'll be doing a lot more of those. To track the WatchpointSP in the WatchpointResources, I changed the internal API which took a WatchpointSP and devolved it to a Watchpoint*, which meant touching several different Process files. I removed the watchpoint code in ProcessKDP which only reported that watchpoints aren't supported, the base class does that already. I haven't yet changed how we receive a watchpoint to identify the WatchpointResource responsible for the trigger, and identify all Watchpoints that are using this Resource to evaluate their conditions etc. This is the same work that a BreakpointSite needs to do when it has been tiggered, where multiple Breakpoints may be at the same address. There is not yet any printing of the Resources that a Watchpoint is implemented in terms of ("watchpoint list", or SBWatchpoint::GetDescription). "watchpoint set var" and "watchpoint set expression" take a size argument which was previously 1, 2, 4, or 8 (an enum). I've changed this to an unsigned int. Most hardware implementations can only watch 1, 2, 4, 8 byte ranges, but with Resources we'll allow a user to ask for different sized watchpoints and set them in hardware-expressble terms soon. I've annotated areas where I know there is work still needed with LWP_TODO that I'll be working on once this is landed. I've tested this on aarch64 macOS, aarch64 Linux, and Intel macOS. https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116 (cherry picked from commit fc6b72523f3d73b921690a713e97a433c96066c6)
2023-11-28Revert "[lldb] [mostly NFC] Large WP foundation: WatchpointResources (#68845)"David Spickett1-2/+2
...and follow ups. As it has caused test failures on Linux Arm and AArch64: https://lab.llvm.org/buildbot/#/builders/96/builds/49126 https://lab.llvm.org/buildbot/#/builders/17/builds/45824 ``` lldb-shell :: Subprocess/clone-follow-child-wp.test lldb-shell :: Subprocess/fork-follow-child-wp.test lldb-shell :: Subprocess/vfork-follow-child-wp.test ``` This reverts commit a6c62bf1a4717accc852463b664cd1012237d334, commit a0a1ff3ab40e347589b4e27d8fd350c600526735 and commit fc6b72523f3d73b921690a713e97a433c96066c6.
2023-11-27[lldb] [mostly NFC] Large WP foundation: WatchpointResources (#68845)Jason Molenda1-2/+2
This patch is rearranging code a bit to add WatchpointResources to Process. A WatchpointResource is meant to represent a hardware watchpoint register in the inferior process. It has an address, a size, a type, and a list of Watchpoints that are using this WatchpointResource. This current patch doesn't add any of the features of WatchpointResources that make them interesting -- a user asking to watch a 24 byte object could watch this with three 8 byte WatchpointResources. Or a Watchpoint on 1 byte at 0x1002 and a second watchpoint on 1 byte at 0x1003, these must both be served by a single WatchpointResource on that doubleword at 0x1000 on a 64-bit target, if two hardware watchpoint registers were used to track these separately, one of them may not be hit. Or if you have one Watchpoint on a variable with a condition set, and another Watchpoint on that same variable with a command defined or different condition, or ignorecount, both of those Watchpoints need to evaluate their criteria/commands when their WatchpointResource has been hit. There's a bit of code movement to rearrange things in the direction I'll need for implementing this feature, so I want to start with reviewing & landing this mostly NFC patch and we can focus on the algorithmic choices about how WatchpointResources are shared and handled as they're triggeed, separately. This patch also stops printing "Watchpoint <n> hit: old value: <x>, new vlaue: <y>" for Read watchpoints. I could make an argument for print "Watchpoint <n> hit: current value <x>" but the current output doesn't make any sense, and the user can print the value if they are particularly interested. Read watchpoints are used primarily to understand what code is reading a variable. This patch adds more fallbacks for how to print the objects being watched if we have types, instead of assuming they are all integral values, so a struct will print its elements. As large watchpoints are added, we'll be doing a lot more of those. To track the WatchpointSP in the WatchpointResources, I changed the internal API which took a WatchpointSP and devolved it to a Watchpoint*, which meant touching several different Process files. I removed the watchpoint code in ProcessKDP which only reported that watchpoints aren't supported, the base class does that already. I haven't yet changed how we receive a watchpoint to identify the WatchpointResource responsible for the trigger, and identify all Watchpoints that are using this Resource to evaluate their conditions etc. This is the same work that a BreakpointSite needs to do when it has been tiggered, where multiple Breakpoints may be at the same address. There is not yet any printing of the Resources that a Watchpoint is implemented in terms of ("watchpoint list", or SBWatchpoint::GetDescription). "watchpoint set var" and "watchpoint set expression" take a size argument which was previously 1, 2, 4, or 8 (an enum). I've changed this to an unsigned int. Most hardware implementations can only watch 1, 2, 4, 8 byte ranges, but with Resources we'll allow a user to ask for different sized watchpoints and set them in hardware-expressble terms soon. I've annotated areas where I know there is work still needed with LWP_TODO that I'll be working on once this is landed. I've tested this on aarch64 macOS, aarch64 Linux, and Intel macOS. https://discourse.llvm.org/t/rfc-large-watchpoint-support-in-lldb/72116
2023-04-17[lldb] Change some pointers to refs in register printing codeDavid Spickett1-1/+1
No one was passing nullptr for these. Reviewed By: JDevlieghere Differential Revision: https://reviews.llvm.org/D148228
2022-07-25[LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scan. Part 2Slava Gurevich1-2/+8
Improve LLDB reliability by fixing the following "uninitialized variables" static code inspection warnings from scan.coverity.com: 1476275, 1274012, 1455035, 1364789, 1454282 1467483, 1406152, 1406255, 1454837, 1454416 1467446, 1462022, 1461909, 1420566, 1327228 1367767, 1431254, 1467299, 1312678, 1431780 1454731, 1490403 Differential Revision: https://reviews.llvm.org/D130528
2022-07-25Revert "[LLDB][NFC][Reliability] Fix uninitialized variables from Coverity ↵Slava Gurevich1-9/+3
scan. Part 2" This reverts commit b9aedd94e6796e4b4866ab4c091b736b3db58cb7.
2022-07-25[LLDB][NFC][Reliability] Fix uninitialized variables from Coverity scan. Part 2Slava Gurevich1-3/+9
Improve LLDB reliability by fixing the following "uninitialized variables" static code inspection warnings from scan.coverity.com: 1476275, 1274012, 1455035, 1364789, 1454282 1467483, 1406152, 1406255, 1454837, 1454416 1467446, 1462022, 1461909, 1420566, 1327228 1367767, 1431254, 1467299, 1312678, 1431780 1454731, 1490403 Differential Revision: https://reviews.llvm.org/D130528
2022-02-03[lldb] Rename Logging.h to LLDBLog.h and clean up includesPavel Labath1-0/+1
Most of our code was including Log.h even though that is not where the "lldb" log channel is defined (Log.h defines the generic logging infrastructure). This worked because Log.h included Logging.h, even though it should. After the recent refactor, it became impossible the two files include each other in this direction (the opposite inclusion is needed), so this patch removes the workaround that was put in place and cleans up all files to include the right thing. It also renames the file to LLDBLog to better reflect its purpose.
2022-02-02[lldb] Convert "LLDB" log channel to the new APIPavel Labath1-7/+6
2021-11-11[lldb][NFC] Inclusive Language: rename master plan to controlling planQuinn Pham1-1/+1
[NFC] As part of using inclusive language within the llvm project, this patch renames master plan to controlling plan in lldb. Reviewed By: jingham Differential Revision: https://reviews.llvm.org/D113019
2021-08-01[lldb] Avoid moving ThreadPlanSP from plans vectorDave Lee1-1/+1
Change `ThreadPlanStack::PopPlan` and `::DiscardPlan` to not do the following: 1. Move the last plan, leaving a moved `ThreadPlanSP` in the plans vector 2. Operate on the last plan 3. Pop the last plan off the plans vector This leaves a period of time where the last element in the plans vector has been moved. I am not sure what, if any, guarantees there are when doing this, but it seems like it would/could leave a null `ThreadPlanSP` in the container. There are asserts in place to prevent empty/null `ThreadPlanSP` instances from being pushed on to the stack, and so this could break that invariant during multithreaded access to the thread plan stack. An open question is whether this use of `std::move` was the result of a measure performance problem. Differential Revision: https://reviews.llvm.org/D106171
2021-02-15[lldb] Minor refinements to ThreadPlan::RestoreThreadState (NFC)Dave Lee1-2/+2
Correct `RestoreThreadState` to a `void` return type. Also, update the signature of its callee, `Thread::RestoreThreadStateFromCheckpoint`, by updating it to a `void` return type, and making it non-`virtual`. Differential Revision: https://reviews.llvm.org/D96688
2020-07-30[lldb] Don't use static locals for return value storage in some *AsCString ↵Raphael Isemann1-3/+3
functions Let's just return a std::string to make this safe. formatv seemed overkill for formatting the return values as they all just append an integer value to a constant string. Reviewed By: labath Differential Revision: https://reviews.llvm.org/D84505
2020-04-03Make ThreadPlans use TID and Process, rather than Thread *.Jim Ingham1-22/+17
Differential Revision: https://reviews.llvm.org/D75711
2020-01-24[lldb][NFC] Fix all formatting errors in .cpp file headersRaphael Isemann1-1/+1
Summary: A *.cpp file header in LLDB (and in LLDB) should like this: ``` //===-- TestUtilities.cpp -------------------------------------------------===// ``` However in LLDB most of our source files have arbitrary changes to this format and these changes are spreading through LLDB as folks usually just use the existing source files as templates for their new files (most notably the unnecessary editor language indicator `-*- C++ -*-` is spreading and in every review someone is pointing out that this is wrong, resulting in people pointing out that this is done in the same way in other files). This patch removes most of these inconsistencies including the editor language indicators, all the different missing/additional '-' characters, files that center the file name, missing trailing `===//` (mostly caused by clang-format breaking the line). Reviewers: aprantl, espindola, jfb, shafik, JDevlieghere Reviewed By: JDevlieghere Subscribers: dexonsmith, wuzish, emaste, sdardis, nemanjai, kbarton, MaskRay, atanasyan, arphaman, jfb, abidh, jsji, JDevlieghere, usaxena95, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D73258
2019-07-24[Logging] Replace Log::Printf with LLDB_LOG macro (NFC)Jonas Devlieghere1-55/+46
This patch replaces explicit calls to log::Printf with the new LLDB_LOGF macro. The macro is similar to LLDB_LOG but supports printf-style format strings, instead of formatv-style format strings. So instead of writing: if (log) log->Printf("%s\n", str); You'd write: LLDB_LOG(log, "%s\n", str); This change was done mechanically with the command below. I replaced the spurious if-checks with vim, since I know how to do multi-line replacements with it. find . -type f -name '*.cpp' -exec \ sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" + Differential revision: https://reviews.llvm.org/D65128 llvm-svn: 366936
2019-07-19[Target] Return an llvm::Expected from GetEntryPointAddress (NFC)Jonas Devlieghere1-10/+8
Instead of taking a status and potentially returning an invalid address, return an expected which is guaranteed to contain a valid address. llvm-svn: 366521
2019-07-18Fall back to dyld's _dyld_start when no LC_MAIN / main() func can be foundJason Molenda1-29/+8
The new DriverKit user-land kernel drivers in macOS 10.15 / Catalina do not have a main() function or an LC_MAIN load command. lldb uses the address of main() as the return address for inferior function calls; it puts a breakpoint on main, runs the inferior function call, and when the main() breakpoint is hit, lldb knows unambiguously that the inferior function call ran to completion - no other function calls main. This change hoists the logic for finding the "entry address" from ThreadPlanCallFunction to Target. It changes the logic to first try to get the entry address from the main executable module, but if that module does not have one, it will iterate through all modules looking for an entry address. The patch also adds code to ObjectFileMachO to use dyld's _dyld_start function as an entry address. <rdar://problem/52343958> Differential Revision: https://reviews.llvm.org/D64897 llvm-svn: 366493
2019-04-10[NFC] Remove ASCII lines from commentsJonas Devlieghere1-2/+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
2019-02-11Use std::make_shared in LLDB (NFC)Jonas Devlieghere1-2/+4
Unlike std::make_unique, which is only available since C++14, std::make_shared is available since C++11. Not only is std::make_shared a lot more readable compared to ::reset(new), it also performs a single heap allocation for the object and control block. Differential revision: https://reviews.llvm.org/D57990 llvm-svn: 353764
2019-01-19Update the file headers across all of the LLVM projects in the monorepoChandler Carruth1-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
2018-11-11Remove header grouping comments.Jonas Devlieghere1-4/+0
This patch removes the comments grouping header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdates and burdensome to maintain. llvm-svn: 346626
2018-07-24Move dumping code out of RegisterValue classPavel Labath1-1/+3
Summary: The dump function was the only part of this class which depended on high-level functionality. This was due to the DumpDataExtractor function, which uses info from a running target to control dump format (although, RegisterValue doesn't really use the high-level part of DumpDataExtractor). This patch follows the same approach done for the DataExtractor class, and extracts the dumping code into a separate function/file. This file can stay in the higher level code, while the RegisterValue class and anything that does not depend in dumping can stay go to lower layers. The XCode project will need to be updated after this patch. Reviewers: zturner, jingham, clayborg Subscribers: lldb-commits, mgorny Differential Revision: https://reviews.llvm.org/D48351 llvm-svn: 337832
2018-04-30Reflow paragraphs in comments.Adrian Prantl1-27/+21
This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2017-05-12Rename Error -> Status.Zachary Turner1-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
2017-03-03Move Log from Core -> Utility.Zachary Turner1-1/+1
All references to Host and Core have been removed, so this class can now safely be lowered into Utility. Differential Revision: https://reviews.llvm.org/D30559 llvm-svn: 296909
2017-02-05Remove LIBLLDB_LOG_VERBOSE categoryPavel Labath1-3/+2
Summary: Per discussion in D28616, having two ways two request logging (log enable lldb XXX verbose && log enable -v lldb XXX) is confusing. This removes the first option and standardizes all code to use the second one. I've added a LLDB_LOGV macro as a shorthand for if(log && log->GetVerbose()) and switched most of the affected log statements to use that (I've only left a couple of cases that were doing complex computations in an if(log) block). Reviewers: jingham, zturner Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D29510 llvm-svn: 294113
2017-02-02Move classes from Core -> Utility.Zachary Turner1-1/+1
This moves the following classes from Core -> Utility. ConstString Error RegularExpression Stream StreamString The goal here is to get lldbUtility into a state where it has no dependendencies except on itself and LLVM, so it can be the starting point at which to start untangling LLDB's dependencies. These are all low level and very widely used classes, and previously lldbUtility had dependencies up to lldbCore in order to use these classes. So moving then down to lldbUtility makes sense from both the short term and long term perspective in solving this problem. Differential Revision: https://reviews.llvm.org/D29427 llvm-svn: 293941
2016-11-16Don't allow direct access to StreamString's internal buffer.Zachary Turner1-2/+2
This is a large API change that removes the two functions from StreamString that return a std::string& and a const std::string&, and instead provide one function which returns a StringRef. Direct access to the underlying buffer violates the concept of a "stream" which is intended to provide forward only access, and makes porting to llvm::raw_ostream more difficult in the future. Differential Revision: https://reviews.llvm.org/D26698 llvm-svn: 287152
2016-09-06*** This commit represents a complete reformatting of the LLDB source codeKate Stone1-479/+406
*** 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
2015-12-15Fix Clang-tidy modernize-use-nullptr and readability-simplify-boolean-expr ↵Eugene Zelenko1-22/+6
warnings in some files in source/Target/. Simplify smart pointers checks in conditions. Other minor fixes. llvm-svn: 255598
2015-08-11ClangASTType is now CompilerType.Greg Clayton1-2/+2
This is more preparation for multiple different kinds of types from different compilers (clang, Pascal, Go, RenderScript, Swift, etc). llvm-svn: 244689
2015-07-14Expression evaluation, a new ThreadPlanCallFunctionUsingABI for executing a ↵Ewan Crawford1-12/+40
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
2015-05-07Add a missing check for m_real_stop_reason.Jim Ingham1-1/+1
<rdar://problem/20738527> llvm-svn: 236762
2015-03-18Move lldb-log.cpp to core/Logging.cppZachary Turner1-1/+0
So that we don't have to update every single #include in the entire codebase to #include this new header (which used to get included by lldb-private-log.h, we automatically #include "Logging.h" from within "Log.h". llvm-svn: 232653
2015-03-03Reduce header footprint of Target.hZachary Turner1-0/+1
This continues the effort to reduce header footprint and improve build speed by removing clang and other unnecessary headers from Target.h. In one case, some headers were included solely for the purpose of declaring a nested class in Target, which was not needed by anybody outside the class. In this case the definition and implementation of the nested class were isolated in the .cpp file so the header could be removed. llvm-svn: 231107
2014-04-08Fix the behavior when hand-calling a function times out on one thread,Jim Ingham1-0/+8
but by the time we go to halt, it has already stopped by hitting the function end breakpoint. That wasn't being shown to the threads so the Function call thread plan didn't know its job was done. <rdar://problem/16515785> llvm-svn: 205803
2014-04-04sweep up -Wformat warnings from gccSaleem Abdulrasool1-26/+43
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
2014-04-02Workaround for collision between enum members in LLVM's MachO.h and system ↵Jim Ingham1-1/+1
headers on Mac OS X (in particular mach/machine.h). <rdar://problem/16494607> llvm-svn: 205480
2014-03-07The ThreadPlanCallFunction needs to pass its "StopOthers" to its run to ↵Jim Ingham1-0/+7
address subplan. llvm-svn: 203231
2014-02-28Plumb the EvaluateExpressionOptions::{Set,Get}StopOthers through the SB API, ↵Jim Ingham1-11/+0
and make it work in RunThreadPlan. Also remove SetStopOthers from the ThreadPlanCallFunction, because if the value you have doesn't match what is in the EvaluateExpressionOptions the plan was passed when created it won't work correctly. llvm-svn: 202464
2013-11-12Log failure to restore thread state in ThreadPlanCallFunction::DoTakedownEd Maste1-1/+5
In order to help track down llvm.org/pr17226. llvm-svn: 194487
2013-11-08Changed the ABIs and ClangFunction to take aSean Callanan1-82/+7
llvm::ArrayRef of arguments rather than taking a fixed number of possibly-NULL pointers to arguments. Also changed ClangFunction::GetThreadPlanToCallFunction to take the address of the argument struct by value instead of by reference, since it doesn't actually modify the value passed into it. llvm-svn: 194232
2013-11-07This patch does a couple of things. Jim Ingham1-39/+51
It completes the job of using EvaluateExpressionOptions consistently throughout the inferior function calling mechanism in lldb begun in Greg's patch r194009. It removes a handful of alternate calls into the ClangUserExpression/ClangFunction/ThreadPlanCallFunction which were there for convenience. Using the EvaluateExpressionOptions removes the need for them. Using that it gets the --debug option from Greg's patch to work cleanly. It also adds another EvaluateExpressionOption to not trap exceptions when running expressions. You shouldn't use this option unless you KNOW your expression can't throw beyond itself. This is: <rdar://problem/15374885> At present this is only available through the SB API's or python. It fixes a bug where function calls would unset the ObjC & C++ exception breakpoints without checking whether they were set by somebody else already. llvm-svn: 194182
2013-06-04If ThreadPlanCallFunction hasn't set its notion of the "real stop info" yet, ↵Jim Ingham1-3/+3
just return the current PrivateStopInfo. Also renamed a few more places where we were using StopReason in functions that were returning StopInfo's. <rdar://problem/14042692> llvm-svn: 183177
2013-05-16Handle the case where there is a user breakpoint set at the location of one ↵Jim Ingham1-0/+8
of our function call exception catching breakpoints. We need to force ourselves to stop in that case. <rdar://problem/13903801> llvm-svn: 182056
2013-05-08Figure out the reply to "PlanExplainsStop" once when we stop and then use ↵Jim Ingham1-3/+3
the cached value. This fixes problems, for instance, with the StepRange plans, where they know that they explained the stop because they were at their "run to here" breakpoint, then deleted that breakpoint, so when they got asked again, doh! I had done this for a couple of plans in an ad hoc fashion, this just formalizes it. Also add a "ResumeRequested" in Process so that the code in the completion handlers can tell the ShouldStop logic they want to resume rather than just directly resuming. That allows us to handle resuming in a more controlled fashion. Also, SetPublicState can take a "restarted" flag, so that it doesn't drop the run lock when the target was immediately restarted. --This line, and those below , will be ignored-- M test/lang/objc/objc-dynamic-value/TestObjCDynamicValue.py M include/lldb/Target/ThreadList.h M include/lldb/Target/ThreadPlanStepOut.h M include/lldb/Target/Thread.h M include/lldb/Target/ThreadPlanBase.h M include/lldb/Target/ThreadPlanStepThrough.h M include/lldb/Target/ThreadPlanStepInstruction.h M include/lldb/Target/ThreadPlanStepInRange.h M include/lldb/Target/ThreadPlanStepOverBreakpoint.h M include/lldb/Target/ThreadPlanStepUntil.h M include/lldb/Target/StopInfo.h M include/lldb/Target/Process.h M include/lldb/Target/ThreadPlanRunToAddress.h M include/lldb/Target/ThreadPlan.h M include/lldb/Target/ThreadPlanCallFunction.h M include/lldb/Target/ThreadPlanStepOverRange.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.h M source/Plugins/LanguageRuntime/ObjC/AppleObjCRuntime/AppleThreadPlanStepThroughObjCTrampoline.cpp M source/Target/StopInfo.cpp M source/Target/Process.cpp M source/Target/ThreadPlanRunToAddress.cpp M source/Target/ThreadPlan.cpp M source/Target/ThreadPlanCallFunction.cpp M source/Target/ThreadPlanStepOverRange.cpp M source/Target/ThreadList.cpp M source/Target/ThreadPlanStepOut.cpp M source/Target/Thread.cpp M source/Target/ThreadPlanBase.cpp M source/Target/ThreadPlanStepThrough.cpp M source/Target/ThreadPlanStepInstruction.cpp M source/Target/ThreadPlanStepInRange.cpp M source/Target/ThreadPlanStepOverBreakpoint.cpp M source/Target/ThreadPlanStepUntil.cpp M lldb.xcodeproj/xcshareddata/xcschemes/Run Testsuite.xcscheme llvm-svn: 181381
2013-03-28Return a useful error message from ValidatePlan if the expression can't be ↵Jim Ingham1-7/+23
made for some reason. llvm-svn: 178201
2013-03-27<rdar://problem/13521159>Greg Clayton1-5/+5
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
generated by cgit v1.1 at 2025-10-01 04:41:40 +0000