summaryrefslogtreecommitdiffstats
path: root/lldb/source/Target
Commit message (Collapse)AuthorAgeFilesLines
...
* Extend FindTypes with CompilerContext to allow filtering by language.Adrian Prantl2019-08-222-41/+22
| | | | | | | | | | | | | | | | | This patch is also motivated by the Swift branch and is effectively NFC for the single-TypeSystem llvm.org branch. In multi-language projects it is extremely common to have, e.g., a Clang type and a similarly-named rendition of that same type in another language. When searching for a type It is much cheaper to pass a set of supported languages to the SymbolFile than having it materialize every result and then rejecting the materialized types that have the wrong language. Differential Revision: https://reviews.llvm.org/D66546 <rdar://problem/54471165> llvm-svn: 369690
* [lldb] D66174 `RegularExpression` cleanupJan Kratochvil2019-08-201-3/+3
| | | | | | | | | | I find as a good cleanup to drop the Compile method. As I do not find TIMTOWTDI as an advantage and there is already constructor parameter to compile the regex. Differential Revision: https://reviews.llvm.org/D66392 llvm-svn: 369352
* [Utility] Reimplement RegularExpression on top of llvm::RegexJonas Devlieghere2019-08-161-19/+10
| | | | | | | | | | | | | | | Originally I wanted to remove the RegularExpression class in Utility and replace it with llvm::Regex. However, during that transition I noticed that there are several places where need the regular expression string. So instead I propose to keep the RegularExpression class and make it a thin wrapper around llvm::Regex. This patch also removes the workaround for empty regular expressions. The result is that we are now (more or less) POSIX conformant. Differential revision: https://reviews.llvm.org/D66174 llvm-svn: 369153
* Stop-hooks weren't getting called on step-out. Fix that.Jim Ingham2019-08-152-4/+9
| | | | | | | | | | | | | | | | There was a little bit of logic in the StopInfoBreakpoint::PerformAction that would null out the StopInfo once we had a completed plan so that the next call to GetStopInfo would replace it with the StopInfoThreadPlan. But the stop-hooks check for whether a thread stopped for a reason didn't trigger this conversion. So I added an API to do that directly, and then called it where before we just reset the StopInfo. <rdar://problem/54270767> Differential Revision: https://reviews.llvm.org/D66241 llvm-svn: 369052
* [LLDB] Migrate llvm::make_unique to std::make_uniqueJonas Devlieghere2019-08-141-1/+1
| | | | | | | | | | Now that we've moved to C++14, we no longer need the llvm::make_unique implementation from STLExtras.h. This patch is a mechanical replacement of (hopefully) all the llvm::make_unique instances across the monorepo. Differential revision: https://reviews.llvm.org/D66259 llvm-svn: 368933
* [ExecutionContext] Return the target/process byte order.Jonas Devlieghere2019-08-071-2/+2
| | | | | | | | | | | | | Currently ExecutionContext::GetByteOrder() always returns the host byte order. This seems like a simple mistake: the return keyword appears to have been omitted by accident. This patch fixes that and adds a unit test. Bugreport: https://llvm.org/PR37950 Differential revision: https://reviews.llvm.org/D48704 llvm-svn: 368181
* Upstream a few small Apple changes to debugserver - arm64_32, CatalystJason Molenda2019-08-071-1/+1
| | | | | | | | | Adrian's changes to support Catalyst processes and my changes to support debugserver running on an arm64_32 device (Apple Watch Series 4, which uses an IPL32 model on arm64 cpus). llvm-svn: 368118
* Remove usage of usleep in generic codePavel Labath2019-08-051-1/+1
| | | | | | | | This function is not portable, and there are only a handful of usages of it anyway. Replacing it with std::this_thread::sleep_for enables us to get rid of the compatibility code in PosixApi.h. llvm-svn: 367814
* Rename F_{None,Text,Append} to OF_{None,Text,Append}. NFCFangrui Song2019-08-051-1/+1
| | | | | | F_{None,Text,Append} are kept for compatibility since r334221. llvm-svn: 367800
* Fix PC adjustment in StackFrame::GetSymbolContextJoseph Tremoulet2019-08-022-25/+39
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Update StackFrame::GetSymbolContext to mirror the logic in RegisterContextLLDB::InitializeNonZerothFrame that knows not to do the pc decrement when the given frame is a signal trap handler frame or the parent of one, because the pc may not follow a call in these frames. Accomplish this by adding a behaves_like_zeroth_frame field to lldb_private::StackFrame, set to true for the zeroth frame, for signal handler frames, and for parents of signal handler frames. Also add logic to propagate the signal handler flag from UnwindPlan to the FrameType on the RegisterContextLLDB it generates, and factor out a helper to resolve symbol and address range for an Address now that we need to invoke it in four places. Reviewers: jasonmolenda, clayborg, jfb Reviewed By: jasonmolenda Subscribers: labath, dexonsmith, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D64993 llvm-svn: 367691
* Format OptionEnumValueElement (NFC)Jonas Devlieghere2019-08-022-50/+119
| | | | | | | | | | Reformat OptionEnumValueElement to make it easier to distinguish between its fields. This also removes the need to disable clang-format for these arrays. Differential revision: https://reviews.llvm.org/D65489 llvm-svn: 367638
* [API] Remove use of ClangASTContext from SBTargetAlex Langford2019-07-311-0/+28
| | | | | | | | | | | | | Summary: The methods to find types in a Target aren't clang specific and are pretty generalizable to type systems. Additionally, to support some of the use cases in SBTarget, I've added a "GetScratchTypeSystems" method to Target to support getting all type systems for a target we are debugging. Differential Revision: https://reviews.llvm.org/D64964 llvm-svn: 367480
* [Symbol] Use llvm::Expected when getting TypeSystemsAlex Langford2019-07-303-64/+74
| | | | | | | | | | | | | | | | | | Summary: This commit achieves the following: - Functions used to return a `TypeSystem *` return an `llvm::Expected<TypeSystem *>` now. This means that the result of a call is always checked, forcing clients to move more carefully. - `TypeSystemMap::GetTypeSystemForLanguage` will either return an Error or a non-null pointer to a TypeSystem. Reviewers: JDevlieghere, davide, compnerd Subscribers: jdoerfert, lldb-commits Differential Revision: https://reviews.llvm.org/D65122 llvm-svn: 367360
* [lldb] Qualify includes of Properties[Enum].inc files. NFCJordan Rupprecht2019-07-296-14/+14
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: This is a bit more explicit, and makes it possible to build LLDB without varying the -I lines per-directory. (The latter is useful because many build systems only allow this to be configured per-library, and LLDB is insufficiently layered to be split into multiple libraries on stricter build systems). (My comment on D65185 has some more context) Reviewers: JDevlieghere, labath, chandlerc, jdoerfert Reviewed By: labath Subscribers: mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D65397 Patch by Sam McCall! llvm-svn: 367241
* [lldb] Also include the array definition in Properties.incJonas Devlieghere2019-07-294-56/+46
| | | | | | | | | | | | | | | | Right now our Properties.inc only generates the initializer for the options list but not the array declaration boilerplate around it. As the array definition is identical for all arrays, we might as well also let the Properties.inc generate it alongside the initializers. Unfortunately we cannot do the same for enums, as there's this magic ePropertyExperimental, which needs to come at the end to be interpreted correctly. Hopefully we can get rid of this in the future and do the same for the property enums. Differential revision: https://reviews.llvm.org/D65353 llvm-svn: 367238
* [TableGen] Move target properties into a separate file (NFC)Jonas Devlieghere2019-07-266-13/+257
| | | | | | | With the plugins having their own tablgen file, it makes sense to split off the target properties as well. llvm-svn: 367139
* Let tablegen generate property definitionsJonas Devlieghere2019-07-255-304/+31
| | | | | | | | | | | | | | | | | | | | | | | | | | Property definitions are currently defined in a PropertyDefinition array and have a corresponding enum to index in this array. Unfortunately this is quite error prone. Indeed, just today we found an incorrect merge where a discrepancy between the order of the enum values and their definition caused the test suite to fail spectacularly. Tablegen can streamline the process of generating the property definition table while at the same time guaranteeing that the enums stay in sync. That's exactly what this patch does. It adds a new tablegen file for the properties, building on top of the infrastructure that Raphael added recently for the command options. It also introduces two new tablegen backends: one for the property definitions and one for their corresponding enums. It might be worth mentioning that I generated most of the tablegen definitions from the existing property definitions, by adding a dump method to the struct. This seems both more efficient and less error prone that copying everything over by hand. Only Enum properties needed manual fixup for the EnumValues and DefaultEnumValue fields. Differential revision: https://reviews.llvm.org/D65185 llvm-svn: 367058
* [Logging] Replace Log::Printf with LLDB_LOG macro (NFC)Jonas Devlieghere2019-07-2425-912/+806
| | | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Logging] Fix format stringsJonas Devlieghere2019-07-231-8/+6
| | | | | | | Change format strings to use the `{}` syntax instead of the printf syntax when using LLDB_LOG. llvm-svn: 366824
* [Logging] Replace LogIfAnyCategoriesSet with LLDB_LOG.Jonas Devlieghere2019-07-221-9/+8
| | | | | | | | This patch removes any remaining instances of LogIfAnyCategoriesSet and replaces them with the LLDB_LOG macro. This in turn made it possible to make Log::VAPrintf and Log::VAError private. llvm-svn: 366768
* [Target] Fix formatting and whitespace (NFC)Jonas Devlieghere2019-07-191-158/+148
| | | | llvm-svn: 366522
* [Target] Return an llvm::Expected from GetEntryPointAddress (NFC)Jonas Devlieghere2019-07-192-33/+30
| | | | | | | 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
* Fall back to dyld's _dyld_start when no LC_MAIN / main() func can be foundJason Molenda2019-07-182-29/+46
| | | | | | | | | | | | | | | | | | | | | | | | | 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
* [Target][NFCI] Remove commented out codeAlex Langford2019-07-171-2/+0
| | | | llvm-svn: 366295
* [Target][NFCI] Rename variableAlex Langford2019-07-171-8/+8
| | | | | | This variable doesn't have anything to do with clang. llvm-svn: 366292
* [Target] Remove unused method Target::GetDefaultClangModuleSearchPathsAlex Langford2019-07-161-7/+0
| | | | llvm-svn: 366161
* [LanguageRuntime] Move ObjCLanguageRuntime into a pluginAlex Langford2019-07-152-436/+0
| | | | | | | | | | | | | | Summary: Following up to my CPPLanguageRuntime change, I'm moving ObjCLanguageRuntime into a plugin as well. Reviewers: JDevlieghere, compnerd, jingham, clayborg Subscribers: mgorny, arphaman, lldb-commits Differential Revision: https://reviews.llvm.org/D64763 llvm-svn: 366148
* [LanguageRuntime] Move CPPLanguageRuntime into a pluginAlex Langford2019-07-122-355/+0
| | | | | | | | | | | | Summary: This seems better suited to be in a plugin. Reviewers: JDevlieghere, clayborg, jingham, compnerd, labath Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D64599 llvm-svn: 365951
* [Core] Generalize ValueObject::MaybeCalculateCompleteTypeAlex Langford2019-07-121-0/+35
| | | | | | | | | | | | | | | | Summary: Instead of hardcoding ClangASTContext and ObjCLanguageRuntime, we can generalize this by creating the method GetRuntimeType in LanguageRuntime and moving the current MaybeCalculateCompleteType implementation into ObjCLanguageruntime::GetRuntimeType Reviewers: jingham, clayborg, JDevlieghere Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D64159 llvm-svn: 365939
* [Expression] Move IRDynamicChecks to ClangExpressionParserAlex Langford2019-07-122-2/+2
| | | | | | | | | | | | | | | | | | Summary: IRDynamicChecks in its current form is specific to Clang since it deals with the C language family. It is possible that we may want to instrument code generated for other languages, but we can factor in a more general mechanism to do so at a later time. This decouples ObCLanguageRuntime from Expression! Reviewers: compnerd, clayborg, jingham, JDevlieghere Subscribers: mgorny, lldb-commits Differential Revision: https://reviews.llvm.org/D64591 llvm-svn: 365853
* [Target] Replace Plugin headers with non-plugin headersAlex Langford2019-07-111-2/+1
| | | | llvm-svn: 365843
* Change LaunchThread interface to return an expected.Jonas Devlieghere2019-07-051-6/+12
| | | | | | | | | Change the interface to return an expected, instead of taking a Status pointer. Differential revision: https://reviews.llvm.org/D64163 llvm-svn: 365226
* [Core] Generalize ValueObject::IsRuntimeSupportValueAlex Langford2019-07-012-27/+2
| | | | | | | | | | | | | | | Summary: Instead of falling back to ObjCLanguageRuntime, we should be falling back to every loaded language runtime. This makes ValueObject more language agnostic. Reviewers: labath, compnerd, JDevlieghere, davide Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D63240 llvm-svn: 364845
* Make sure the thread list is updated before you set the stop reasonJim Ingham2019-06-281-1/+9
| | | | | | | | | | | | | | | on a thread. When talking to some older gdb-remote stubs, We were getting a stop reason from the stop reply packet and setting it on the relevant thread before we updated the full stop list. That would get discarded when the full list was updated. Also, if you already have a thread list when you go to see if there is an Operating System plugin, and you do indeed load a new OS plugin, you have to re-fetch the thread list or it will only show the raw threads. Differential Revision: https://reviews.llvm.org/D62887 llvm-svn: 364666
* Add a defensive check for nullptr as in the block above.Adrian Prantl2019-06-251-1/+1
| | | | | | | | | Unfortunately I had to work backwards from a crash log, so I don't have a good testcase at this point in time. rdar://problem/51874647 llvm-svn: 364344
* Remove core loading timeoutPavel Labath2019-06-251-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: If target.preload-symbols is false, waiting for the process to "stop" can take an arbitrarily long amount of time, because it will cause all the debug info to be parsed (to compute the stop message showing the function, its arguments, etc). We were previously waiting for 10 seconds for the stop even to arrive, which is a pretty long time, but it's not that hard to overcome with huge debug info. Since any arbitrary limit can be theoretically overcome with huge debug_info and/or slow machine, and the stop even was sent 3 lines above the wait, if we ever do not receive the stop even means we've got a bug in lldb. Therefore, I remove the timeout on this wait completely. No test because I don't know how to reproduce this without a multi-gigabyte symbol file. Reviewers: jingham, clayborg Subscribers: aprantl, lldb-commits Differential Revision: https://reviews.llvm.org/D63730 llvm-svn: 364276
* [Target] Decouple ObjCLanguageRuntime from LanguageRuntimeAlex Langford2019-06-213-20/+33
| | | | | | | | | | | | Summary: ObjCLanguageRuntime was being pulled into LanguageRuntime because of Breakpoint Preconditions. If we move BreakpointPrecondition out of Breakpoint, we can extend the LanguageRuntime plugin interface so that LanguageRuntimes can give us a BreakpointPrecondition for exceptions. Differential Revision: https://reviews.llvm.org/D63181 llvm-svn: 364098
* [LanguageRuntime] Simplify CreateExceptionSearchFilter in derived classesAlex Langford2019-06-111-3/+0
| | | | llvm-svn: 363109
* Add support to read aux vector valuesAntonio Afonso2019-06-111-1/+1
| | | | | | | | | | | | | | | | | | | | Summary: This is the second patch to improve module loading in a series that started here (where I explain the motivation and solution): https://reviews.llvm.org/D62499 I need to read the aux vector to know where the r_debug map with the loaded libraries are. The AuxVector class was made generic so it could be reused between the POSIX-DYLD plugin and NativeProcess*. The class itself ended up in the ProcessUtility plugin. Reviewers: clayborg, xiaobai, labath, JDevlieghere Reviewed By: clayborg, labath, JDevlieghere Subscribers: emaste, JDevlieghere, mgorny, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D62500 llvm-svn: 363098
* [Target] Use llvm::scope_exit to restore m_suppress_stop_hooks value.Tatyana Krasnukha2019-06-101-4/+5
| | | | llvm-svn: 362985
* [Target] Remove Process::GetObjCLanguageRuntimeAlex Langford2019-06-101-8/+0
| | | | | | | | | | | Summary: In an effort to make Process more language agnostic, I removed GetCPPLanguageRuntime from Process. I'm following up now with an equivalent change for ObjC. Differential Revision: https://reviews.llvm.org/D63052 llvm-svn: 362981
* [Target] Remove unused header from ProcessAlex Langford2019-06-081-1/+0
| | | | | | | I forgot to remove this when I removed GetCPPLanguageRuntime from Process llvm-svn: 362885
* [LanguageRuntime] Introduce LLVM-style castsAlex Langford2019-06-084-4/+7
| | | | | | | | | | | | Summary: Using llvm-style rtti gives us stronger guarantees around casting LanguageRuntimes. As discussed in D62755 Differential Revision: https://reviews.llvm.org/D62934 llvm-svn: 362884
* [Target] Remove Process::GetCPPLanguageRuntimeAlex Langford2019-06-041-10/+0
| | | | | | | | | | | | | | | | | | | | | Summary: I want to remove this method because I think that Process should be language agnostic, or at least, not have knowledge about specific language runtimes. There is "GetLanguageRuntime()" which should be used instead. If the caller a CPPLanguageRuntime, they should cast it as needed. Ideally, this should only happen in plugins that need C++ specific knowledge. The next step I would like to do is remove "GetObjCLanguageRuntime()" as well. There are a lot more instances of that function being used, so I wanted to upload this one first to get the general reception to this idea. Reviewers: compnerd, davide, JDevlieghere, jingham, clayborg, labath, aprantl Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D62755 llvm-svn: 362544
* [Target] Generalize some behavior in Target::SymbolsDidLoadAlex Langford2019-06-031-6/+2
| | | | | | | | | | | | Summary: SymbolsDidLoad is currently only implemented for ObjCLanguageRuntime, but that doesn't mean that it couldn't be useful for other Langauges. Although this change seems like it's generalizing for the sake of purity, this removes Target's dependency on ObjCLanguageRuntime. Differential Revision: https://reviews.llvm.org/D62796 llvm-svn: 362461
* [Target] Adjust header in ThreadAlex Langford2019-06-021-1/+1
| | | | llvm-svn: 362318
* [Target] Remove ABI's dependence on ExpressionParserAlex Langford2019-05-311-5/+5
| | | | llvm-svn: 362259
* [Target] Generalize language-specific behavior in ThreadPlanStepThroughAlex Langford2019-05-301-16/+10
| | | | | | | | | | | | Summary: When creating a ThreadPlan to step through a trampoline, we ask the ObjC language runtime and the CPP language runtime to come up with such a thread plan if the dynamic loader fails to give us one. I don't see why this behavior can't be language agnostic. Differential Revision: https://reviews.llvm.org/D61921 llvm-svn: 362164
* [Target] Generalize Process::IsPossibleDynamicValueAlex Langford2019-05-301-5/+5
| | | | llvm-svn: 362154
* [Target] Sink some asserts into Process::GetLanguageRuntimeAlex Langford2019-05-291-5/+14
| | | | llvm-svn: 362032
OpenPOWER on IntegriCloud