summaryrefslogtreecommitdiffstats
path: root/lldb/source/Core
Commit message (Collapse)AuthorAgeFilesLines
...
* minor refactoring to remove unneeded/unspecific header filesVince Harron2015-01-161-4/+0
| | | | | | Differential review: http://reviews.llvm.org/D6919 llvm-svn: 226249
* Moved Args::StringToXIntYZ to StringConvert::ToXIntYZVince Harron2015-01-152-4/+6
| | | | | | | | | | The refactor was motivated by some comments that Greg made http://reviews.llvm.org/D6918 and also to break a dependency cascade that caused functions linking in string->int conversion functions to pull in most of lldb llvm-svn: 226199
* Fix a little thinko in r226017 - the code to actually add the demangled name ↵Jim Ingham2015-01-151-4/+6
| | | | | | | | | | | | | to the Mangled object got moved into the #else branch of the #if/#elif/#endif, so it wasn't getting done in the #if case anymore. Keep the code to add the demangled name outside of the #if, and then just free the demangled_name and set it back to NULL in the Windows case. <rdar://problem/19479499> llvm-svn: 226088
* Modified LLDB to be able to lookup global variables by address.Greg Clayton2015-01-151-2/+2
| | | | | | | | | | | | This is done by adding a "Variable *" to SymbolContext and allowing SymbolFile::ResolveSymbolContext() so if an address is resolved into a symbol context, we can include the global or static variable for that address. This means you can now find global variables that are merged globals when doing a "image lookup --verbose --address 0x1230000". Previously we would resolve a symbol and show "_MergedGlobals123 + 1234". But now we can show the global variable name. The eSymbolContextEverything purposely does not include the new eSymbolContextVariable in its lookup since stack frame code does many lookups and we don't want it triggering the global variable lookups. <rdar://problem/18945678> llvm-svn: 226084
* Three related changes to help:Kate Stone2015-01-151-0/+12
| | | | | | | | | | | | | | | | The default help display now shows the alias collection by default, and hides commands whose named begin with an underscore. Help is primarily useful to those unfamiliar with LLDB and should aim to answer typical questions while still being able to provide more esoteric answers when required. To that latter end an argument to include the hidden commands in help has been added, and instead of having a help flag to show aliases there is now one to hide them. This final change might be controversial as it repurposes the -a shorthand as the opposite of its original meaning. The previous implementation of OutputFormattedHelpText was easily confused by embedded newlines. The new algorithm correctly breaks on the FIRST newline or LAST space/tab before the target column count rather than treating all whitespace interchangeably. Command interpreters now have the ability to specify help prologue text and a command prefix string. Neither are used in the current LLDB sources but are required to support REPL-like extensions where LLDB commands must be prefixed and additional help text is required to explain how to access traditional debugging commands. <rdar://problem/17751929> <rdar://problem/16953815> <rdar://problem/16953841> <rdar://problem/16930173> <rdar://problem/16879028> llvm-svn: 226068
* Implement demangling on Windows.Zachary Turner2015-01-141-7/+22
| | | | llvm-svn: 226017
* Make the list of synthetic children thread safeEnrico Granata2015-01-091-12/+12
| | | | | | | | | | | | | I have been seeing a few crashes where LLDB tries to acquire a cached synthetic child by index, and crashes in the ClusterManager obtaining a shared_ptr for that ValueObject That kind of crash most often means that I am holding on to a raw pointer to a ValueObject that was let go from the cluster The main way that could happen is that the synthetic provider is being updated at the same time that some child is being accessed from the previous provider state This fixes the problem by making the children be stored in a thread-safe map Fixes rdar://18627964 llvm-svn: 225538
* This patch fixes my think-o in ValueObject::UpdateValueIfNeeded() about the ↵Enrico Granata2015-01-081-2/+2
| | | | | | | | | right thing to assert() It also comes with a (rudimentary) test case that gets itself in a failed update scenario, and checks that we don't crash This is the easiest case I could think of that forces the failed update case Zachary was seeing llvm-svn: 225463
* Fix a problem where a ValueObject could fail to update itself, but since it ↵Enrico Granata2015-01-081-1/+1
| | | | | | was previously valid, we'd have an old checksum to compare aginst no new checksum (because failure to update), and assert() and die. Fix the problem by only caring about this assertion logic if updates succeed llvm-svn: 225418
* Cleanup some redundant codeEnrico Granata2014-12-201-3/+1
| | | | llvm-svn: 224659
* Audit uses of ConstString::AsCString() to make sure they weren't assumingJim Ingham2014-12-194-8/+10
| | | | | | | | they would always get a non-NULL string back. <rdar://problem/19298575> llvm-svn: 224602
* Fixed an issue that could cause GetPointeeData() to fail when passing in a ↵Greg Clayton2014-12-191-5/+34
| | | | | | | | | | non-zero index. The issue was we had a global variable that was a pointer, and the address type of the children wasn't "load address" when it needed to be. Full details are in the comments of the changes. <rdar://problem/15107937> llvm-svn: 224559
* Provide CreateValueFromData,Expression at the SBTarget level as well as the ↵Enrico Granata2014-12-171-2/+13
| | | | | | SBValue level; and also make all the implenentations agree on using the matching ValueObject::Create instead of doing code copypastas llvm-svn: 224460
* In C++, it's #include not #importEnrico Granata2014-12-161-1/+1
| | | | llvm-svn: 224352
* Instead of rolling our own, use the C++11 sanctioned solutionEnrico Granata2014-12-161-13/+6
| | | | llvm-svn: 224310
* Some more cleanup of the ValueObjectConstResultImpl code. NFC.Enrico Granata2014-12-121-17/+0
| | | | llvm-svn: 224160
* The so-called "trivial implementation" has been with us for a few years now. ↵Enrico Granata2014-12-121-34/+0
| | | | | | It's probably safe to assume it works.. so remove the #if stuff llvm-svn: 224147
* Do attempt to ask the impl_backend for the live address of a const result if ↵Enrico Granata2014-12-121-1/+1
| | | | | | none is stored in the object itself; this is for symmetry with GetAddressOf() llvm-svn: 224143
* Do not set the live address of a const result child if its parent has an ↵Enrico Granata2014-12-121-1/+2
| | | | | | invalid live address llvm-svn: 224142
* Remove the last vestige of the world before data formatters :-)Enrico Granata2014-12-101-59/+4
| | | | | | | | Function pointers had a summary generated for them bypassing formatters, directly as part of the ValueObject subsystem This patch transitions that code into a hardcoded summary llvm-svn: 223906
* Handle thumb IT instructions correctly all the time.Greg Clayton2014-12-091-0/+110
| | | | | | | | | | | | | | | | | | | | | | The issue with Thumb IT (if/then) instructions is the IT instruction preceeds up to four instructions that are made conditional. If a breakpoint is placed on one of the conditional instructions, the instruction either needs to match the thumb opcode size (2 or 4 bytes) or a BKPT instruction needs to be used as these are always unconditional (even in a IT instruction). If BKPT instructions are used, then we might end up stopping on an instruction that won't get executed. So if we do stop at a BKPT instruction, we need to continue if the condition is not true. When using the BKPT isntructions are easy in that you don't need to detect the size of the breakpoint that needs to be used when setting a breakpoint even in a thumb IT instruction. The bad part is you will now always stop at the opcode location and let LLDB determine if it should auto-continue. If the BKPT instruction is used, the BKPT that is used for ARM code should be something that also triggers the BKPT instruction in Thumb in case you set a breakpoint in the middle of code and the code is actually Thumb code. A value of 0xE120BE70 will work since the lower 16 bits being 0xBE70 happens to be a Thumb BKPT instruction. The alternative is to use trap or illegal instructions that the kernel will translate into breakpoint hits. On Mac this was 0xE7FFDEFE for ARM and 0xDEFE for Thumb. The darwin kernel currently doesn't recognize any 32 bit Thumb instruction as a instruction that will get turned into a breakpoint exception (EXC_BREAKPOINT), so we had to use the BKPT instruction on Mac. The linux kernel recognizes a 16 and a 32 bit instruction as valid thumb breakpoint opcodes. The benefit of using 16 or 32 bit instructions is you don't stop on opcodes in a IT block when the condition doesn't match. To further complicate things, single stepping on ARM is often implemented by modifying the BCR/BVR registers and setting the processor to stop when the PC is not equal to the current value. This means single stepping is another way the ARM target can stop on instructions that won't get executed. This patch does the following: 1 - Fix the internal debugserver for Apple to use the BKPT instruction for ARM and Thumb 2 - Fix LLDB to catch when we stop in the middle of a Thumb IT instruction and continue if we stop at an instruction that won't execute 3 - Fixes this in a way that will work for any target on any platform as long as it is ARM/Thumb 4 - Adds a patch for ignoring conditions that don't match when in ARM mode (see below) This patch also provides the code that implements the same thing for ARM instructions, though it is disabled for now. The ARM patch will check the condition of the instruction in ARM mode and continue if the condition isn't true (and therefore the instruction would not be executed). Again, this is not enable, but the code for it has been added. <rdar://problem/19145455> llvm-svn: 223851
* Extend ValueObject::GetExpressionPath() to do something reasonable for ↵Enrico Granata2014-12-091-0/+40
| | | | | | | | | | | | | | | | | | | synthetic children Because of the way they are created, synthetic children cannot (in general) have a sane expression path A solution to this would be letting the parent front-end generate expression paths for its children Doing so requires a significant amount of refactoring, and might not always lead to better results (esp. w.r.t. C++ templates) This commit takes a simpler approach: - if a synthetic child is of pointer type and it's a target pointer, then emit *((T)value) - if a synthetic child is a non-pointer, but its location is in the target, then emit *((T*)loadAddr) - if a synthetic child has a value, emit ((T)value) - else, don't emit anything Fixes rdar://18442386 llvm-svn: 223836
* Fixed ValueObject::UpdateValueIfNeeded to keepSean Callanan2014-12-092-11/+72
| | | | | | | | | | track of the checksum of the object so we can track if it is modified. This fixes a testcase (test/expression_command/issue_11588) on OS X. Patch by Enrico Granata. llvm-svn: 223830
* This patch does a few things:Enrico Granata2014-12-091-2/+16
| | | | | | | | | | - adds a new flag to mark ValueObjects as "synthetic children generated" - vends new Create functions as part of the SyntheticChildrenFrontEnd that set the flag automatically - moves synthetic child providers over to using these new functions No visible feature change, but preparatory work for feature change llvm-svn: 223819
* Add the ability for an SBValue to create a persisted version of itself.Enrico Granata2014-12-082-4/+34
| | | | | | | | | | | | Such a persisted version is equivalent to evaluating the value via the expression evaluator, and holding on to the $n result of the expression, except this API can be used on SBValues that do not obviously come from an expression (e.g. are the result of a memory lookup) Expose this via SBValue::Persist() in our public API layer, and ValueObject::Persist() in the lldb_private layer Includes testcase Fixes rdar://19136664 llvm-svn: 223711
* Improvements to FastDemangler to correct parsing of <local-name> encodings ↵Kate Stone2014-12-061-0/+4
| | | | | | for string literal and parameter/entity cases. Patch courtesy of slydiman. llvm-svn: 223569
* Add the ability to set breakpoints with conditions, commands, etc,Jim Ingham2014-12-062-26/+70
| | | | | | | | | | | | | | in the "dummy-target". The dummy target breakpoints prime all future targets. Breakpoints set before any target is created (e.g. breakpoints in ~/.lldbinit) automatically get set in the dummy target. You can also list, add & delete breakpoints from the dummy target using the "-D" flag, which is supported by most of the breakpoint commands. This removes a long-standing wart in lldb... <rdar://problem/10881487> llvm-svn: 223565
* Fix the behavior of ${current-pc-arrow} in the default disassemblyJason Molenda2014-12-021-7/+8
| | | | | | | | | | | | format for the not-current-stack-frame. This was causing test/functionalities/inferior-assert to fail. Also document the new additions to the format specifications used in the disassembly-format changes to formats.html. <rdar://problem/19102757> llvm-svn: 223096
* lldb can deadlock when launched with an non-existing executable:Greg Clayton2014-12-011-10/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | % lldb /bin/nonono (lldb) target create "/bin/nonono" error: unable to find executable for '/usr/bin/nonono' <deadlock> The problem was the initial commands 'target create "/bin/nonono"' were put into a pipe and the command interpreter was being run with: void CommandInterpreter::RunCommandInterpreter(bool auto_handle_events, bool spawn_thread, CommandInterpreterRunOptions &options) { // Always re-create the command intepreter when we run it in case // any file handles have changed. bool force_create = true; m_debugger.PushIOHandler(GetIOHandler(force_create, &options)); m_stopped_for_crash = false; if (auto_handle_events) m_debugger.StartEventHandlerThread(); if (spawn_thread) { m_debugger.StartIOHandlerThread(); } else { m_debugger.ExecuteIOHanders(); if (auto_handle_events) m_debugger.StopEventHandlerThread(); } } If "auto_handle_events" was set to true and "spawn_thread" was false, we would execute: m_debugger.StartEventHandlerThread(); m_debugger.ExecuteIOHanders(); m_debugger.StopEventHandlerThread(); The problem was there was no synchonization in Debugger::StartEventHandlerThread() to ensure the event handler was listening to events and the the call to "m_debugger.StopEventHandlerThread()" would do: void Debugger::StopEventHandlerThread() { if (m_event_handler_thread.IsJoinable()) { GetCommandInterpreter().BroadcastEvent(CommandInterpreter::eBroadcastBitQuitCommandReceived); m_event_handler_thread.Join(nullptr); } } The problem was that the event thread might not be listening for the CommandInterpreter::eBroadcastBitQuitCommandReceived event yet. The solution is to make sure the Debugger::DefaultEventHandler() is listening to events before we return from Debugger::StartEventHandlerThread(). Once we have this synchonization we remove the race condition. This fixes radar: <rdar://problem/19041192> llvm-svn: 223083
* This is the first step of making lldb able to create target-specific thingsJim Ingham2014-11-221-0/+15
| | | | | | | | | | | | | (e.g. breakpoints, stop-hooks) before we have any targets - for instance in your ~/.lldbinit file. These will then get copied over to any new targets that get created. So far, you can only make stop-hooks. Breakpoints will have to learn to move themselves from target to target for us to get them from no-target to new-target. We should also make a command & SB API way to prime this ur-target. llvm-svn: 222600
* Fix broken build after removing StringMap::GetOrCreateValue in favor of ↵Oleksiy Vyalov2014-11-191-3/+3
| | | | | | StringMap::insert. llvm-svn: 222370
* Shuffle APIs around a little bit, so that if you pass custom summary ↵Enrico Granata2014-11-181-7/+10
| | | | | | options, we don't end up caching the summary hence obtained. You may want to obtain an uncapped summary, but this should not be reflected in the summary we cache. The drawback is that we don't cache as aggressively as we could, but at least you get to have different summaries with different options without having to reset formatters or the SBValue at each step llvm-svn: 222280
* Disable Editline on Windows.Zachary Turner2014-11-171-7/+4
| | | | | | | | | | | | | | | | | | | | Editline does not work correctly on Windows. This goes back at least to r208369, and as a result r210105 was submitted to disable libedit at runtime on Windows. More recently, r222163 was submitted which re-writes editline entirely, but makes the situation even worse on Windows, to the point that it doesn't even compile. While it would be easy to fix the compilation failure, this patch simply stops compiling Editline entirely on Windows, as the simple compilation fix would still result in a broken use of select on Windows, and as such a broken implementation of Editline. Since Editline was already disabled to begin with on Windows, we don't attempt to fix the compilation failure or the underlying issues, and instead just disable it "even more". llvm-svn: 222177
* Complete rewrite of interactive editing support for single- and multi-line ↵Kate Stone2014-11-171-45/+138
| | | | | | | | | | | | | | | | | | | input. Improvements include: * Use of libedit's wide character support, which is imperfect but a distinct improvement over ASCII-only * Fallback for ASCII editing path * Support for a "faint" prompt clearly distinguished from input * Breaking lines and insert new lines in the middle of a batch by simply pressing return * Joining lines with forward and backward character deletion * Detection of paste to suppress automatic formatting and statement completion tests * Correctly reformatting when lines grow or shrink to occupy different numbers of rows * Saving multi-line history, and correctly preserving the "tip" of history during editing * Displaying visible ^C and ^D indications when interrupting input or sending EOF * Fledgling VI support for multi-line editing * General correctness and reliability improvements llvm-svn: 222163
* For some reason, sometimes the directory paths that clang emits have internalJim Ingham2014-11-151-2/+2
| | | | | | | | | | | | | | | | | | | | | relative paths, like: /whatever/llvm/lib/Sema/../../include/llvm/Sema/ That causes problems with our type uniquing, since we use the declaration file and line as one component of the uniquing, and different ways of getting to the same file will have different directory spellings, though they are functionally equivalent. We end up with two copies of the exact same type because of this, and that makes the expression parser give "duplicate type" errors. I added a method to resolve paths with ../ in them and used that in the FileSpec::Equals, for comparing Declarations and for doing Breakpoint compares as well, since they also suffer from this if you specify breakpoints by full path (since nobody knows what ../'s to insert...) <rdar://problem/18765814> llvm-svn: 222075
* Sketch out the armv7 and arm64 core file writing support inJason Molenda2014-11-121-2/+2
| | | | | | | | | | | | | | | ObjectFileMachO. It's close but we seem to be missing some of the memory region segments - not exactly sure how that's happening. The register context writing into the LC_THREAD load commands is working correctly though. Slightly reordered the arm64 definitions in ArchSpec.cpp so when we look for an arm64 core file definiton we're getting a cpu subtype of CPU_ANY which we can't put in the mach header of a core file. Make the first definition we find by linear search have the currently correct '1' cpu subtype. llvm-svn: 221743
* Put the current pc arrow back into the default disassembly format.Jason Molenda2014-11-111-1/+1
| | | | | | | | | I went back and forth on removing this - and tried dropping it for a few weeks. But when you're working at an assembly language, it really is helpful to have this displayed to show where the current pc is. llvm-svn: 221682
* LLGS Android target support - for Andy Chien : http://reviews.llvm.org/D6166Shawn Best2014-11-081-0/+2
| | | | llvm-svn: 221570
* This is a large, but clearical, commit that enables the C++ formatters to ↵Enrico Granata2014-11-062-2/+2
| | | | | | take on the additional TypeSummaryOptions argument. It is still not used for anything, but it is now there. Adding support for this extra argument to Python formatters will follow suit llvm-svn: 221486
* Introduce the notion of "type summary options" as flags that can be passed ↵Enrico Granata2014-11-062-1/+45
| | | | | | | | | | | | | down to individual summary formatters to alter their behavior in a formatter-dependent way Two flags are introduced: - preferred display language (as in, ObjC vs. C++) - summary capping (as in, should a limit be put to the amount of data retrieved) The meaning - if any - of these options is for individual formatters to establish The topic of a subsequent commit will be to actually wire these through to individual data formatters llvm-svn: 221482
* Add a setting escape-non-printables that drives whether the StringPrinter ↵Enrico Granata2014-11-052-4/+16
| | | | | | | | | | | should or should not escape sequences such as \t, \n, .. and generally any non-printing character The recent StringPrinter changes made this behavior the default, and the setting defaults to yes If you want to change this behavior and see non-printables unescaped (e.g. "a\tb" as "a b"), set it to false Fixes rdar://12969594 llvm-svn: 221399
* Fix a problem where ValueObjectVariable was not correctly setting its 'has ↵Enrico Granata2014-11-041-0/+2
| | | | | | value changed' flag for scalar valued variables. This fixes rdar://17851144 llvm-svn: 221298
* In ValueObjectDynamicValue, trust what comes fromSean Callanan2014-10-311-10/+1
| | | | | | | | | | | the runtime rather than trying to fix it up, because now those types have ivars regardless of whether they come from "frame variable" or from expressions. Patch by Enrico Granata. llvm-svn: 220982
* Fix some bugs from D5988Justin Hibbits2014-10-311-1/+0
| | | | | | | | | | | | | | | | | | Summary: Ed Maste found some problems with the commit in D5988. Address most of these. While here, also add floating point return handling. This doesn't handle 128-bit long double yet. Since I don't have any system that uses it, I don't currently have plans to implement it. Reviewers: emaste Reviewed By: emaste Subscribers: emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D6049 llvm-svn: 220963
* Update default disassembly format string so we getJason Molenda2014-10-311-2/+1
| | | | | | | | | | | | | | | | | better output when we don't have any symbol name. It looked like this: 0x1097fd029 <ud2 0x1097fd02b <addb %al, (%rax) now, like this: 0x10cdd3064: ud2 0x10cdd3066: addb %al, (%rax) <rdar://problem/18833391> llvm-svn: 220948
* First cut of PowerPC(64) support in LLDB.Justin Hibbits2014-10-311-2/+3
| | | | | | | | | | | | | | | | | | | | | | | Summary: This adds preliminary support for PowerPC/PowerPC64, for FreeBSD. There are some issues still: * Breakpoints don't work well on powerpc64. * Shared libraries don't yet get loaded for a 32-bit process on powerpc64 host. * Backtraces don't work. This is due to PowerPC ABI using a backchain pointer in memory, instead of a dedicated frame pointer register for the backchain. * Breakpoints on functions without debug info may not work correctly for 32-bit powerpc. Reviewers: emaste, tfiala, jingham, clayborg Reviewed By: clayborg Subscribers: emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D5988 llvm-svn: 220944
* Also port the C string reading code in ValueObject over to using ↵Enrico Granata2014-10-301-32/+36
| | | | | | StringPrinter API llvm-svn: 220917
* Add a feature where a string data formatter can now be partially composed of ↵Enrico Granata2014-10-281-0/+9
| | | | | | | | | | | | | | Python summary functions This works similarly to the {thread/frame/process/target.script:...} feature - you write a summary string, part of which is ${var.script:someFuncName} someFuncName is expected to be declared as def someFuncName(SBValue,otherArgument) - essentially the same as a summary function Since . -> [] are the only allowed separators, and % is used for custom formatting, .script: would not be a legitimate symbol anyway, which makes this non-ambiguous llvm-svn: 220821
* Setting breakpoints with name mask eFunctionNameTypeBase was broken for ↵Jim Ingham2014-10-251-20/+11
| | | | | | | | straight C names by 220432. Get that working again. llvm-svn: 220602
* Implement explicit thread stack size specification on Windows.Zachary Turner2014-10-241-5/+4
| | | | llvm-svn: 220596
OpenPOWER on IntegriCloud