summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/Utility
Commit message (Collapse)AuthorAgeFilesLines
...
* Rearrange RegisterContextLLDB::SavedLocationForRegister a tiny bitJason Molenda2015-01-081-18/+22
| | | | | | | | | | | | | so that we will use the UnwindPlan's rule for providing the stack pointer BEFORE we use the trick of using the callee's CFA address as the stack pointer. When we're in a _sigtramp frame, the CFA of the _sigtramp stack frame is not the same as the stack pointer value when the async interrupt occurred -- we need to use the eh_frame rules for retrieving the correct value. <rdar://problem/18913548> llvm-svn: 225427
* Make sure if a thread specifies a 'register_data_addr' in a python operating ↵Greg Clayton2014-12-111-1/+1
| | | | | | system plug-in, that is is used to fetch the register values. llvm-svn: 224083
* Make sure we print errors for python OperatingSystem plug-ins for when ↵Greg Clayton2014-12-111-0/+12
| | | | | | things go wrong. We also dump the dictionary or collection that had errors so the user can see which info was wrong. llvm-svn: 224082
* Handle thumb IT instructions correctly all the time.Greg Clayton2014-12-092-4/+38
| | | | | | | | | | | | | | | | | | | | | | 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
* Add a new 'eRegisterInLiveRegisterContext' RegisterLocation to trackJason Molenda2014-12-093-9/+44
| | | | | | | | | | | | | | a register value that is live in the stack frame 0 register context. Fixes a problem where retrieving a register value on stack frame #n would involved O(n!) stack frame checks. This could be very slow on a deep stack when retrieving register values that had not been modified/saved by any of the stack frames. Not common, but annoying when it was hit. <rdar://problem/19010211> llvm-svn: 223843
* The lldb unwinder can now use the unwind information from the compact-unwind Jason Molenda2014-12-081-4/+7
| | | | | | | | | | | | | | | | | | section for x86_64 and i386 targets on Darwin systems. Currently only the compact unwind encoding for normal frame-using functions is supported but it will be easy handle frameless functions when I have a bit more free time to test it. The LSDA and personality routines for functions are also retrieved correctly for functions from the compact unwind section. This new code is very fresh -- it passes the lldb testsuite and I've done by-hand inspection of many functions and am getting correct behavior for all of them. There may need to be some bug fixing over the next couple weeks as I exercise and test it further. But I think it's fine right now so I'm committing it. <rdar://problem/13220837> llvm-svn: 223625
* When a RegisterContext produces an invalid CFA address, changeJason Molenda2014-11-222-15/+42
| | | | | | | | | | | | | | | | | UnwindLLDB::AddOneMoreFrame to try the fallback unwind plan on that same stack frame before it tries the fallback unwind plan on the "next" or callee frame. In RegisterContextLLDB::TryFallbackUnwindPlan, when we're trying the fallback unwind plan to see if it is valid, make sure we change all of the object ivars that might be used in the process of fetching the CFA & caller's saved pc value and restore those if we decide not to use the fallback unwindplan. <rdar://problem/19035079> llvm-svn: 222601
* Rename lldb registers to contain lldb_ prefix.Zachary Turner2014-11-214-545/+546
| | | | | | | | | | | | | | | | | | | | LLDB supports many different register numbering schemes, and these are typically prefixed with an indicator that lets the user know what numbering scheme is used. The gcc numbering scheme is prefixed with gcc, and there are similar ones for dwarf, gdb, and gcc_dwarf. LLDB also contains its own internal numbering scheme, but the enum for LLDB's numbering scheme was prefixed differently. This patch changes the names of these enums to use the same naming scheme for the enum values as the rest of the register kinds by removing gpr_ and fpu_ prefixes, and instead using lldb_ prefixes for all enum values. Differential Revision: http://reviews.llvm.org/D6351 Reviewed by: Greg Clayton llvm-svn: 222495
* Remove duplicated enum, use the authoritative one.Zachary Turner2014-11-201-275/+2
| | | | | | | | | Running a diff against lldb-x86-register-enums.h and the file modified in this patch, the two enums were completely identical. Deleting one of them to reduce code noise. llvm-svn: 222478
* Add additional checks to the SavedLocationForRegister methodJason Molenda2014-11-191-5/+28
| | | | | | | | | | | | | | where it is retrieving the Return Address register contents on a target where that's a thing. If we fail to get a valid RA, we force a switch to the fallback unwind plan. This patch adds a sanity check for that fallback unwind plan -- it must get a valid CFA for this frame in addition to being able to retrieve the caller's PC -- and it correctly marks the unwind rules as failing if the fallback unwind plan fails. <rdar://problem/19010211> llvm-svn: 222301
* A pretty big overhaul of the TryFallbackUnwindPlan method inJason Molenda2014-11-133-53/+249
| | | | | | | | | | | | RegisterContextLLDB. I have core files of half a dozen tricky unwind situations on x86/arm and they're all working pretty much correctly at this point, but we'll need to keep an eye out for unwinder regressions for a little while; it's tricky to get these heuristics completely correct in all unwind situations. <rdar://problem/18937193> llvm-svn: 221866
* Use PRIx64 when printing addr_t's. Don't need to force full-width 0 paddingJason Molenda2014-11-121-2/+2
| | | | | | with addresses that aren't designed to be column-aligned across multiple lines. llvm-svn: 221810
* Avoid crash in InitializeNonZerothFrame if no module foundEd Maste2014-11-121-1/+2
| | | | | | | | After r221575 TestCallStopAndContinue and TestCallThatRestarts started crashing on FreeBSD with a null temporary_module_sp in RegisterContextLLDB::InitializeNonZerothFrame(). llvm-svn: 221805
* FIx a bug with PC-register handling in a RA register.Justin Hibbits2014-11-121-0/+1
| | | | | | | | | | | The addition of RegisterNumber introduced a bug where if the PC is stored in a return address register, such as on ARM and PowerPC, this register number is retrieved and used, but never checked in the row if it's saved. Correct this by setting the variable that's used to the new register number. Patch by Jason Molenda. llvm-svn: 221790
* Improve PowerPC unwind supportJustin Hibbits2014-11-122-3/+23
| | | | | | | | | | | | | | | | | Summary: Taking advantage of the new 'CFAIsRegisterDereferenced' CFA register type, add full stack unwind support to the PowerPC/PowerPC64 ABI. Also, add a new register set for powerpc32-on-64, so the register sizes are correct. This also requires modifying the ProcessMonitor to add support for non-uintptr_t-sized register values. Reviewers: jasonmolenda, emaste Subscribers: emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D6183 llvm-svn: 221789
* Add an alternative CFA type.Justin Hibbits2014-11-122-25/+46
| | | | | | | | | | | | | | | | | | | Summary: PowerPC handles the stack chain with the current stack pointer being a pointer to the backchain (CFA). LLDB currently has no way of handling this, so this adds a "CFA is dereferenced from a register" type. Discussed with Jason Molenda, who also provided the initial patch for this. Reviewers: jasonmolenda Reviewed By: jasonmolenda Subscribers: emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D6182 llvm-svn: 221788
* Add an operator== to the RegisterNumber class; it simplifiesJason Molenda2014-11-112-7/+43
| | | | | | RegisterContextLLDB a bit more in a few places. llvm-svn: 221677
* Add a RegisterNumber class to RegisterContextLLDB.h and start usingJason Molenda2014-11-082-73/+207
| | | | | | | | | | | | | | | | | | | | | | | it in RegisterContext.cpp. There's a lot of bookkeeping code in RegisterContextLLDB where it has to convert between different register numbering schemes and it makes some methods like SavedLocationForRegister very hard to read or maintain. Abstract all of the details about different register numbering systems for a given register into this new class to make it easier to understand what the method is doing. Also add register name printing to all of the logging -- that's easy to get now that I've got an object to represent the register numbers. There were some gnarly corner cases of this method that I believe I've translated correctly - initial testing looks good but it's possible I missed a corner case, especially with architectures which uses a link-register aka return address register like arm32/arm64. Basic behavior is correct but there are a lot of corner casese that are handled in this method ... llvm-svn: 221577
* Fix a corner case with the handling of noreturn functions.Jason Molenda2014-11-081-9/+45
| | | | | | | | | | | | | | | | | | If a noreturn function was the last function in a section, we wouldn't correctly back up the saved-pc value into the correct section leading to us showing the wrong function in the backtrace. Also add a backtrace test with an attempt to elicit this particular layout. It happens to work out with clang -Os but other compilers may not quite get the same layout I'm getting at that opt setting. We'll still be exercising the basic noreturn handling in the unwinder even if we don't get one function at the very end of a section. <rdar://problem/16051613> llvm-svn: 221575
* LLGS Android target support - for Andy Chien : http://reviews.llvm.org/D6166Shawn Best2014-11-081-1/+1
| | | | llvm-svn: 221570
* Add one extra sanity check to RegisterContextLLDB::TryFallbackUnwindPlanJason Molenda2014-11-041-0/+8
| | | | | | | so it doesn't try the arch default if a comiler-generated (eh_frame, compact unwind info) based unwind plan has failed. llvm-svn: 221239
* Back out r221229 -- instead of trying to identify the end of the unwind,Jason Molenda2014-11-043-36/+9
| | | | | | | | | | | | | | | | | let's let lldb try the arch default unwind every time but not destructively -- it doesn't permanently replace the main unwind method for that function from now on. This fix is for <rdar://problem/18683658>. I tested it against Ryan Brown's go program test case and also a collection of core files of tricky unwind scenarios <rdar://problem/15664282> <rdar://problem/15835846> <rdar://problem/15982682> <rdar://problem/16099440> <rdar://problem/17364005> <rdar://problem/18556719> that I've fixed over the last 6-9 months. llvm-svn: 221238
* After we've completed a full backtrace, we'll have one frame whichJason Molenda2014-11-043-2/+26
| | | | | | | | | | | | | | | | is "invalid" -- it is past the end of the stack trace. Add a new method IsCompletedStackWalk() so we can tell if an invalid stack frame is from a complete backtrace or if it might be worth re-trying the last unwind with a different method. This fixes the unwinder problems Ryan Brown was having with go programs. The unwinder can (under the right circumstances) still destructively replace unwind plans permanently - I'll work on that in a different patch. <rdar://problem/18683658> llvm-svn: 221229
* Always transmit SIGPROF back to the inferior.Stephane Sezer2014-10-311-1/+1
| | | | | | | | | | | | | | | | | | | Summary: SIGPROF is used for profiling processes (with google-perftools for instance), which results in the inferior receiving a SIGPROF from the kernel every few milliseconds. Instead of stopping the debugging session and notifying the user of this, we should just pass the signal and keep running. This follows the behavior we have in UnixSignals.cpp. Test Plan: Run LLDB on linux with a binary using google-perftools, see that execution gets interrupted all the time because we receive SIGPROF. Apply the patch, everything works fine. Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D5953 llvm-svn: 221011
* First cut of PowerPC(64) support in LLDB.Justin Hibbits2014-10-318-1/+1033
| | | | | | | | | | | | | | | | | | | | | | | 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
* A << operation would be undefined for a bit-selectingJason Molenda2014-10-171-1/+1
| | | | | | | | | function because of a '1u' making it a 32-bit value when it really needed to be a 64-bit value. Trivial to fix once I figured out what was going on. clang static analzyer fixit. llvm-svn: 220022
* Be more consistent about null checks for the Process and ABIJason Molenda2014-10-151-7/+14
| | | | | | | | in GetFullUnwindPlanForFrame() - the code was mostly checking that we had an active Process and ABI but not always. clang static analyzer fixit. llvm-svn: 219772
* When we detect a stack unwind loop, before we abortJason Molenda2014-10-071-6/+14
| | | | | | | | the backtrace, try falling back to the architecture default unwind plan and see if we can backtrace a little further. <rdar://problem/18556719> llvm-svn: 219247
* This checkin is the first step in making the lldb thread stepping mechanism ↵Jim Ingham2014-09-291-14/+10
| | | | | | | | | | | | more accessible from the user level. It adds the ability to invent new stepping modes implemented by python classes, and to view the current thread plan stack and to some extent alter it. I haven't gotten to documentation or tests yet. But this should not cause any behavior changes if you don't use it, so its safe to check it in now and work on it incrementally. llvm-svn: 218642
* Enable llgs to build against experimental Android AOSP ↵Todd Fiala2014-09-271-2/+2
| | | | | | | | | | | | lldb/llvm/clang/compiler-rt repos. See http://reviews.llvm.org/D5495 for more details. These are changes that are part of an effort to support building llgs, within the AOSP source tree, using the Android.mk build system, when using the llvm/clang/lldb git repos from AOSP replaced with the experimental ones currently in github.com/tfiala/aosp-{llvm,clang,lldb,compiler-rt}. llvm-svn: 218568
* Remove unused class variable and update all callers/users.Eric Christopher2014-09-093-5/+2
| | | | llvm-svn: 217419
* ASan malloc/free history threadsKuba Brecka2014-09-041-0/+12
| | | | | | Reviewed at http://reviews.llvm.org/D4596 llvm-svn: 217116
* RegisterContextLLDB::InitializeNonZerothFrame had a bit of code toJason Molenda2014-09-022-17/+34
| | | | | | | | | | | | | | | | | | | | detct unwind loops but there was a code path through there (using architecture default unwind plans) that didn't do the check, and could end up with an infinite loop unwind. Move that code into a separate method and call it from both places where it is needed. Also remove the use of ABI::FunctionCallsChangeCFA in that check. I thought about it a lot and none of the architecutres that we're supporting today can have a looping CFA. Since the unwinder isn't using ABI::FunctionCallsChangeCFA() and ABI::StackUsesFrames(), and the unwinder was the only reason those methods exists, I removed them from the ABI and all its plugins. <rdar://problem/17364005> llvm-svn: 216992
* Linux ARM64: add ProcessMonitor-related RegisterContext support.Todd Fiala2014-09-023-0/+572
| | | | | | | | See http://reviews.llvm.org/D5089 for more details. Change by Paul Osmialowski. llvm-svn: 216907
* lldb - Register Context Linux ARM64Todd Fiala2014-08-295-301/+527
| | | | | | | | | | | | | Yet another step toward ARM64 support. With this commit, lldb-gdbserver started on ARM64 target can be accessed by lldb running on desktop PC and it can process simple commands (like 'continue'). Still ARM64 support lacks NativeRegisterContextLinux_arm64.* code which waits to be implemented. Based on similar files for Linux x86_64 and Darwin ARM64. Due to common code extraction from Darwin related files, lldb should be tested for any unexpected regression on Darwin ARM64 machines too. See the following for more details: http://reviews.llvm.org/D4580 http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140825/012670.html Change by Paul Osmialowski. llvm-svn: 216737
* lldb Missing break statement added.Todd Fiala2014-08-271-0/+1
| | | | | | | | See http://reviews.llvm.org/D5069. Change by Paul Osmialowski. llvm-svn: 216554
* On x86 & x86_64, try to use eh_frame for frame 0.Todd Fiala2014-08-251-2/+2
| | | | | | | | | | | | | We decided to use assmbly profiler instead of eh_frame for frame 0 because for compiler generated code, eh_frame is usually synchronous(a.k.a. only valid at call site); and we have no way to tell if it's asynchronous or not. But for x86 & x86_64 compiler generated code: 1. clang & GCC describes all prologue instructions in eh_frame; 2. mid-function stack pointer altering instructions can be easily detected. So we can grab eh_frame, and use assembly profiler to augment it into asynchronous unwind table. This change also benefits hand-written assembly; eh_frame for hand-written assembly is often asynchronous,so we have a much better chance to successfully unwind through them. Change by Tong Shen. llvm-svn: 216406
* gcc_esp_i386 and gcc_ebp_i386 had their values backwards forJason Molenda2014-08-131-2/+10
| | | | | | | | | i386 eh_frame register numbering, encoding a darwin-specific bug in the register numbering. Update the definitions to be the correct values, Darwin can use the register numbers from debugserver. Patch from Tong Shen. llvm-svn: 215488
* Fix incorrect Linux i386 register info initialization on x86_64.Todd Fiala2014-08-121-1/+1
| | | | | | Fix by Tong Shen. llvm-svn: 215424
* Update lldb to track recent Triple arm64 enum removal and collapse into aarch64.Todd Fiala2014-07-231-1/+1
| | | | | | | | | | | See the following llvm change for details: r213743 | tnorthover | 2014-07-23 05:32:47 -0700 (Wed, 23 Jul 2014) | 9 lines AArch64: remove arm64 triple enumerator. This change fixes build breaks on Linux and MacOSX lldb. llvm-svn: 213755
* lldb needs to support DW_op_piece masks for values in subregister and also ↵Greg Clayton2014-07-121-0/+2
| | | | | | | | | | to be able to piece together a value that is spread across multiple registers. Patch from Adrian Prantl. <rdar://problem/16040521> llvm-svn: 212867
* __arm64__ and __aarch64__ #ifdef adjustmentsTodd Fiala2014-07-092-2/+2
| | | | | | | | Change by Paul Osmialowski See http://reviews.llvm.org/D4379 for details. llvm-svn: 212583
* Fix typos.Bruce Mitchener2014-07-084-4/+4
| | | | llvm-svn: 212553
* Replace uint32_t by lldb::RegisterKing in register context API.Jean-Daniel Dupas2014-07-0224-30/+30
| | | | llvm-svn: 212172
* This creates a valid Python API for Windows, pending some issues. The ↵Deepak Panickal2014-07-011-1/+1
| | | | | | | | | | | | | changes included are - - Ported the SWIG wrapper shell scripts to Python so that they would work on Windows too along with other platforms - Updated CMake handling to fix SWIG errors and manage sym-linking on Windows to liblldb.dll - More build fixes for Windows The pending issues are that two Python modules, termios and pexpect are not available on Windows. These are currently required for the Python command interpreter to be used from within LLDB. llvm-svn: 212111
* Fixup Windows build breaks for the llgs upstream.Todd Fiala2014-06-304-1227/+34
| | | | | | | | Also moves NativeRegisterContextLinux* files into the Linux directory. These, like NativeProcessLinux, should only be built on Linux or a cross compiler with proper headers. llvm-svn: 212074
* Add lldb-gdbserver support for Linux x86_64.Todd Fiala2014-06-3017-67/+1755
| | | | | | | | | | | | | | | | | | | | | This change brings in lldb-gdbserver (llgs) specifically for Linux x86_64. (More architectures coming soon). Not every debugserver option is covered yet. Currently the lldb-gdbserver command line can start unattached, start attached to a pid (process-name attach not supported yet), or accept lldb attaching and launching a process or connecting by process id. The history of this large change can be found here: https://github.com/tfiala/lldb/tree/dev-tfiala-native-protocol-linux-x86_64 Until mid/late April, I was not sharing the work and continued to rebase it off of head (developed via id tfiala@google.com). I switched over to user todd.fiala@gmail.com in the middle, and once I went to github, I did merges rather than rebasing so I could share with others. llvm-svn: 212069
* lldb: remove adhoc implementation of array_sizeofSaleem Abdulrasool2014-06-274-20/+25
| | | | | | | | Replace adhoc inline implementation of llvm::array_lengthof in favour of the implementation in LLVM. This is simply a cleanup change, no functional change intended. llvm-svn: 211868
* Temporarily roll back the parts of r211241 where I fixed aJason Molenda2014-06-232-2/+2
| | | | | | | | | | mistake in the lock acquistion in HistoryUnwind and HistoryThread. We've got a deadlock with one use case of HistoryUnwind; I need to figure out what lock ordering is causing this and fix it for real. <rdar://problem/17411904> llvm-svn: 211541
* Add a lock in the UnwindTable class so two Targets won't tryJason Molenda2014-06-182-2/+2
| | | | | | | | | | to modify the same UnwindTable object simultaneously. Fix HistoryThread and HistoryUnwind's mutex lock acqusition to retain the lock for the duration of the operation instead of releasing the temporary immediately. <rdar://problem/17055023> llvm-svn: 211241
OpenPOWER on IntegriCloud