summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/Process/Utility
Commit message (Collapse)AuthorAgeFilesLines
...
* Fix RegisterInfo initializers to have all the required initializers after ↵Greg Clayton2016-08-084-36/+36
| | | | | | recent changes. This quiets a few hundred warnings on MacOSX. llvm-svn: 278060
* [LLVM][MIPS] Fix FPU Size Based on Dynamic FR.Nitesh Jain2016-08-0116-224/+286
| | | | | | | | | | Reviewers: jingham, clayborg Subscribers: jaydeep, bhushan, mohit.bhakkad, slthakur, lldb-commits, emaste, nemanjai, labath, sdardis Differential Revision: https://reviews.llvm.org/D20357 llvm-svn: 277343
* The ARM single-step handling needs to look for breakpoint on the next ↵Jim Ingham2016-07-261-1/+2
| | | | | | | | instruction. <rdar://problem/27006685> llvm-svn: 276796
* Revert r273524, it may have been the cause of a linux testbot failureJason Molenda2016-06-232-2/+2
| | | | | | | | for TestNamespaceLookup.py; didn't see anything obviously wrong so I'll need to look at this more closely before re-committing. (passed OK on macOS ;) llvm-svn: 273531
* Do some minor renames of "Mac OS X" to "macOS".Jason Molenda2016-06-232-2/+2
| | | | | | | | | There's uses of "macosx" that will be more tricky to change, like in triples (e.g. "x86_64-apple-macosx10.11") - for now I'm just updating source comments and strings printed for humans. llvm-svn: 273524
* A better fix of incorrectly used locking in HistoryThread and HistoryUnwind.Kuba Brecka2016-05-222-2/+2
| | | | llvm-svn: 270363
* Revert r270358 ("Fix an incorrectly used locking in HistoryThread and ↵Kuba Brecka2016-05-222-2/+4
| | | | | | HistoryUnwind"). llvm-svn: 270359
* Fix an incorrectly used locking in HistoryThread and HistoryUnwind, where ↵Kuba Brecka2016-05-222-4/+2
| | | | | | unique_lock's release() was called causing the mutex to stay locked. llvm-svn: 270358
* [LLDB][MIPS] Fix Floating point Registers EncodingSagar Thakur2016-05-202-8/+18
| | | | | | | | | | | Patch by Nitesh Jain. Summary: Currently floating point regsiters has eEncodingUint encoding. Hence register write '1.25' will failed. This patch add eEncodingIEEE754 encoding for floating point registers( - ). This patch will fix test_fp_register_write in TestRegisters.py Reviewers: clayborg, sagar Subscribers: mohit.bhakkad, jaydeep, bhushan, sdardis, lldb-commits Differential: D18853 llvm-svn: 270208
* Some changes to prevent searching down the stack for saved registerJason Molenda2016-05-201-10/+29
| | | | | | | | | | | | | | | | | | | | | | | | values for the pc or return address register. On ios with arm64 and a binary that has multiple functions without individual symbol boundaries, we end up with an assembly profile unwind plan that says lr=<same> - that is, the link register contents are unmodified from the caller's value. This gets the unwinder in a loop. When we're off the 0th frame, we never want to look to a caller for a pc or return-address register value. Add checks to ReadGPRValue and ReadRegister to prevent both the pc and ra register values from recursing. If this causes problems with backtraces on android, let me know or back it out and I'll look into it -- but I think these are straightforward and don't expect problems. <rdar://problem/24610365> llvm-svn: 270162
* remove use of Mutex in favour of std::{,recursive_}mutexSaleem Abdulrasool2016-05-184-26/+26
| | | | | | | | | | This is a pretty straightforward first pass over removing a number of uses of Mutex in favor of std::mutex or std::recursive_mutex. The problem is that there are interfaces which take Mutex::Locker & to lock internal locks. This patch cleans up most of the easy cases. The only non-trivial change is in CommandObjectTarget.cpp where a Mutex::Locker was split into two. llvm-svn: 269877
* Fix unwind failures when PC points beyond the end of a functionUlrich Weigand2016-04-241-5/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | RegisterContextLLDB::InitializeNonZerothFrame already has code to attempt to detect and handle the case where the PC points beyond the end of a function, but there are certain cases where this doesn't work correctly. In fact, there are *two* different places where this detection is attempted, and the failure is in fact a result of an unfortunate interaction between those two separate attempts. First, the ResolveSymbolContextForAddress routine is called with the resolve_tail_call_address flag set to true. This causes the routine to internally accept a PC pointing beyond the end of a function, and still resolving the PC to that function symbol. Second, the InitializeNonZerothFrame routine itself maintains a "decr_pc_and_recompute_addr_range" flag and, if that turns out to be true, itself decrements the PC by one and searches again for a symbol at that new PC value. Both approaches correctly identify the symbol associated with the PC. However, the problem is now that later on, we also need to find the DWARF CFI record associated with the PC. This is done in the RegisterContextLLDB::GetFullUnwindPlanForFrame routine, and uses the "m_current_offset_backed_up_one" member variable. However, that variable only actually contains the PC "backed up by one" if the *second* approach above was taken. If the function was already identified via the first approach above, that member variable is *not* backed up by one but simply points to the original PC. This in turn causes GetEHFrameUnwindPlan to not correctly identify the DWARF CFI record associated with the PC. Now, in many cases, if the first method had to back up the PC by one, we *still* use the second method too, because of this piece of code: // Or if we're in the middle of the stack (and not "above" an asynchronous event like sigtramp), // and our "current" pc is the start of a function... if (m_sym_ctx_valid && GetNextFrame()->m_frame_type != eTrapHandlerFrame && GetNextFrame()->m_frame_type != eDebuggerFrame && addr_range.GetBaseAddress().IsValid() && addr_range.GetBaseAddress().GetSection() == m_current_pc.GetSection() && addr_range.GetBaseAddress().GetOffset() == m_current_pc.GetOffset()) { decr_pc_and_recompute_addr_range = true; } In many cases, when the PC is one beyond the end of the current function, it will indeed then be exactly at the start of the next function. But this is not always the case, e.g. if there happens to be alignment padding between the end of one function and the start of the next. In those cases, we may sucessfully look up the function symbol via ResolveSymbolContextForAddress, but *not* set decr_pc_and_recompute_addr_range, and therefore fail to find the correct DWARF CFI record. A very simple fix for this problem is to just never use the first method. Call ResolveSymbolContextForAddress with resolve_tail_call_address set to false, which will cause it to fail if the PC is beyond the end of the current function; or else, identify the next function if the PC is also at the start of the next function. In either case, we will then set the decr_pc_and_recompute_addr_range variable and back up the PC anyway, but this time also find the correct DWARF CFI. A related problem is that the ResolveSymbolContextForAddress sometimes returns a "symbol" with empty name. This turns out to be an ELF section symbol. Now, usually those get type eSymbolTypeInvalid. However, there is code in ObjectFileELF::ParseSymbols that tries to change the type of invalid symbols to eSymbolTypeCode or eSymbolTypeData if the symbol lies within the code or data section. Unfortunately, this check also hits the symbol for the code section itself, which is then marked as eSymbolTypeCode. While the size of the section symbol is 0 according to the ELF file, LLDB considers this size invalid and attempts to figure out the "correct" size. Depending on how this goes, we may end up with a symbol that overlays part of the code section, even outside areas covered by real function symbols. Therefore, if we call ResolveSymbolContextForAddress with PC pointing beyond the end of a function, we may get this bogus section symbol. This again means InitializeNonZerothFrame thinks we have a valid PC, but then we don't find any unwind info for it. The fix for this problem is me to simply always leave ELF section symbols as type eSymbolTypeInvalid. Differential Revision: http://reviews.llvm.org/D18975 llvm-svn: 267363
* Support Linux on SystemZ as platformUlrich Weigand2016-04-148-0/+829
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch adds support for Linux on SystemZ: - A new ArchSpec value of eCore_s390x_generic - A new directory Plugins/ABI/SysV-s390x providing an ABI implementation - Register context support - Native Linux support including watchpoint support - ELF core file support - Misc. support throughout the code base (e.g. breakpoint opcodes) - Test case updates to support the platform This should provide complete support for debugging the SystemZ platform. Not yet supported are optional features like transaction support (zEC12) or SIMD vector support (z13). There is no instruction emulation, since our ABI requires that all code provide correct DWARF CFI at all PC locations in .eh_frame to support unwinding (i.e. -fasynchronous-unwind-tables is on by default). The implementation follows existing platforms in a mostly straightforward manner. A couple of things that are different: - We do not use PTRACE_PEEKUSER / PTRACE_POKEUSER to access single registers, since some registers (access register) reside at offsets in the user area that are multiples of 4, but the PTRACE_PEEKUSER interface only allows accessing aligned 8-byte blocks in the user area. Instead, we use a s390 specific ptrace interface PTRACE_PEEKUSR_AREA / PTRACE_POKEUSR_AREA that allows accessing a whole block of the user area in one go, so in effect allowing to treat parts of the user area as register sets. - SystemZ hardware does not provide any means to implement read watchpoints, only write watchpoints. In fact, we can only support a *single* write watchpoint (but this can span a range of arbitrary size). In LLDB this means we support only a single watchpoint. I've set all test cases that require read watchpoints (or multiple watchpoints) to expected failure on the platform. [ Note that there were two test cases that install a read/write watchpoint even though they nowhere rely on the "read" property. I've changed those to simply use plain write watchpoints. ] Differential Revision: http://reviews.llvm.org/D18978 llvm-svn: 266308
* Add new ABI callback to provide fallback unwind register locationsUlrich Weigand2016-04-141-26/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | If the UnwindPlan did not identify how to unwind the stack pointer register, LLDB currently assumes it can determine to caller's SP from the current frame's CFA. This is true on most platforms where CFA is by definition equal to the incoming SP at function entry. However, on the s390x target, we instead define the CFA to equal the incoming SP plus an offset of 160 bytes. This is because our ABI defines that the caller has to provide a register save area of size 160 bytes. This area is allocated by the caller, but is considered part of the callee's stack frame, and therefore the CFA is defined as pointing to the top of this area. In order to make this work on s390x, this patch introduces a new ABI callback GetFallbackRegisterLocation that provides platform- specific fallback register locations for unwinding. The existing code to handle SP unwinding as well as volatile registers is moved into the default implementation of that ABI callback, to allow targets where that implementation is incorrect to override it. This patch in itself is a no-op for all existing platforms. But it is a pre-requisite for adding s390x support. Differential Revision: http://reviews.llvm.org/D18977 llvm-svn: 266307
* Add a DiagnosticManager replace error streams in the expression parser.Sean Callanan2016-03-191-37/+20
| | | | | | | | | | | | | | | | | | | | | | | | | | | | We want to do a better job presenting errors that occur when evaluating expressions. Key to this effort is getting away from a model where all errors are spat out onto a stream where the client has to take or leave all of them. To this end, this patch adds a new class, DiagnosticManager, which contains errors produced by the compiler or by LLDB as an expression is created. The DiagnosticManager can dump itself to a log as well as to a string. Clients will (in the future) be able to filter out the errors they're interested in by ID or present subsets of these errors to the user. This patch is not intended to change the *users* of errors - only to thread DiagnosticManagers to all the places where streams are used. I also attempt to standardize our use of errors a bit, removing trailing newlines and making clients omit 'error:', 'warning:' etc. and instead pass the Severity flag. The patch is testsuite-neutral, with modifications to one part of the MI tests because it relied on "error: error:" being erroneously printed. This patch fixes the MI variable handling and the testcase. <rdar://problem/22864976> llvm-svn: 263859
* This change introduces a "ExpressionExecutionThread" to the ThreadList. Jim Ingham2016-03-121-3/+3
| | | | | | | | | | | | | | | | | | | Turns out that most of the code that runs expressions (e.g. the ObjC runtime grubber) on behalf of the expression parser was using the currently selected thread. But sometimes, e.g. when we are evaluating breakpoint conditions/commands, we don't select the thread we're running on, we instead set the context for the interpreter, and explicitly pass that to other callers. That wasn't getting communicated to these utility expressions, so they would run on some other thread instead, and that could cause a variety of subtle and hard to reproduce problems. I also went through the commands and cleaned up the use of GetSelectedThread. All those uses should have been trying the thread in the m_exe_ctx belonging to the command object first. It would actually have been pretty hard to get misbehavior in these cases, but for correctness sake it is good to make this usage consistent. <rdar://problem/24978569> llvm-svn: 263326
* Add support for DW_OP_push_object_address in dwarf expressionsTamas Berghammer2016-02-261-2/+2
| | | | | | | | | Additionally fix the type of some dwarf expression where we had a confusion between scalar and load address types after a dereference. Differential revision: http://reviews.llvm.org/D17604 llvm-svn: 262014
* [NetBSD] Remove dead code.Davide Italiano2016-02-031-7/+0
| | | | | PR: http://reviews.llvm.org/D16818 llvm-svn: 259686
* The SetStopInfo from a Mach Exception was setting the stopJim Ingham2016-02-031-0/+2
| | | | | | | | | | reason to None when we stop due to a trace, then noticed that we were on a breakpoint that was not valid for the current thread. That should actually have set it back to trace. This was pr26441 (<rdar://problem/24470203>) llvm-svn: 259684
* NetBSD: Define initial RegisterContextNetBSD_x86_64Kamil Rytarowski2016-02-023-0/+400
| | | | | | | | | | | | Summary: Add basic support, i386 version will be added later. Reviewers: emaste, joerg, clayborg, tfiala Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D16508 llvm-svn: 259462
* Remove autoconf support from source directories.Eugene Zelenko2016-01-281-14/+0
| | | | | | Differential revision: http://reviews.llvm.org/D16662 llvm-svn: 259098
* Some 32-bit arm corefiles on darwin may have their general purposeJason Molenda2016-01-202-4/+7
| | | | | | | | | | register set indicated by ARM_THREAD_STATE32 (value 9) instead of the old ARM_THREAD_STATE (value 1); this patch changes lldb to accept either register set flavor code. <rdar://problem/24246257> llvm-svn: 258289
* Fix for TestNoreturnUnwind.py on i386Ravitheja Addepally2016-01-121-3/+26
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The testcase TestNoreturnUnwind.py was failing because the unwind from the vdso library was not successful for clang compiler while it was passing for gcc. It was passing for gcc since the unwind plan used was the assembly plan and the ebp register was set by the main function in case of gcc and was not used by the functions in the call flow to the vdso, whereas clang did not emit assembly prologue for main and so the assembly unwind was failing. Normally in case of failure of assembly unwind, lldb switches to EH CFI frame based unwinding, but this was not happening for the first frame. This patch tries to fix this behaviour by falling to EH CFI frame based unwinding in case of assembly unwind failure even for the first frame. The test is still marked as XFAIL since it relys on the fix of another bug. Reviewers: lldb-commits, jingham, zturner, tberghammer, jasonmolenda Subscribers: jasonmolenda Differential Revision: http://reviews.llvm.org/D15046 llvm-svn: 257465
* Prevent infinite recursive loop in AppleObjCTrampolineHandler constructorStephane Sezer2016-01-082-2/+7
| | | | | | | | | | | | | | | | | | | | | | | Summary: When we construct AppleObjCTrampolineHandler, if m_impl_fn_addr is invalid, we call CanJIT(). If the gdb remote process does not support allocating and deallocating memory, this call stack will include a call to the AppleObjCRuntime constructor. The AppleObjCRuntime constructor will then call the AppleObjCTrampolineHandler constructor, creating a recursive call loop that eventually overflows the stack and segfaults. Avoid this call loop by not constructing the AppleObjCTrampolineHandler within AppleObjCRuntime until we actually need to use it. Reviewers: clayborg, jingham Subscribers: sas, lldb-commits Differential Revision: http://reviews.llvm.org/D15978 Change by Francis Ricci <fjricci@fb.com> llvm-svn: 257204
* Welcome to NetBSD signalsKamil Rytarowski2015-12-153-0/+66
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Signals 1-32 are matching the default UNIX platform. There are platform specific ones above 32. From the `/usr/include/sys/signal.h` header: ``` #define SIGPWR 32 /* power fail/restart (not reset when caught) */ #ifdef _KERNEL #define SIGRTMIN 33 /* Kernel only; not exposed to userland yet */ #define SIGRTMAX 63 /* Kernel only; not exposed to userland yet */ #endif ``` Reviewers: emaste, joerg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D15482 llvm-svn: 255592
* Add 64/128 bit arm neon register definitions on linuxTamas Berghammer2015-11-265-63/+360
| | | | | | Differential revision: http://reviews.llvm.org/D14985 llvm-svn: 254152
* Fix to solve Bug 23139 & Bug 23560Abhishek Aggarwal2015-11-132-1/+94
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: - Reason of both bugs: 1. For the very first frame, Unwinder doesn't check the validity of Full UnwindPlan before creating StackFrame from it: When 'process launch' command is run after setting a breakpoint in inferior, the Unwinder runs and saves only Frame 0 (the frame in which breakpoint was set) in thread's StackFrameList i.e. m_curr_frames_sp. However, it doesn't check the validity of the Full UnwindPlan for this frame by unwinding 2 more frames further. 2. Unwinder doesn't update the CFA value of Cursor when Full UnwindPlan fails and FallBack UnwindPlan succeeds in providing valid CFA values for frames: Sometimes during unwinding of stack frames, the Full UnwindPlan inside the RegisterContextLLDB object may fail to provide valid CFA values for these frames. Then the Fallback UnwindPlan is used to unwind the frames. If the Fallback UnwindPlan succeeds, then it provides a valid new CFA value. The RegisterContextLLDB::m_cfa field of Cursor object is updated during the Fallback UnwindPlan execution. However, UnwindLLDB misses the implementation to update the 'cfa' field of this Cursor with this valid new CFA value. - This patch fixes both these issues. - Remove XFAIL in test files corresponding to these 2 Bugs Change-Id: I932ea407545ceee2d628f946ecc61a4806d4cc86 Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com> Reviewers: jingham, lldb-commits, jasonmolenda Subscribers: lldb-commits, ovyalov, tberghammer Differential Revision: http://reviews.llvm.org/D14226 llvm-svn: 253026
* Make lldb::endian::InlHostByteOrder() private.Bruce Mitchener2015-11-072-3/+3
| | | | | | | | | | | | | | | | | | Summary: Since this is within the lldb namespace, the compiler tries to export a symbol for it. Unfortunately, since it is inlined, the symbol is hidden and this results in a mess of warnings when building on OS X with cmake. Moving it to the lldb_private namespace eliminates that problem. Reviewers: clayborg Subscribers: emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D14417 llvm-svn: 252396
* [LLDB][MIPS] Fix GetUserRegisterInfoCount to count no of regs which are ↵Mohit K. Bhakkad2015-11-034-10/+26
| | | | | | | | | | physically present Reviewers: clayborg, labath. Subscribers: jaydeep, bhushan, sagar, nitesh.jain, lldb-commits. Differential Revision: http://reviews.llvm.org/D13859 llvm-svn: 251906
* Fix Clang-tidy modernize-use-nullptr warnings in ↵Eugene Zelenko2015-10-307-415/+449
| | | | | | source/Plugins/Process/Utility headers; other minor fixes. llvm-svn: 251676
* Fix Clang-tidy modernize-use-override warnings in some files in ↵Eugene Zelenko2015-10-215-134/+126
| | | | | | | | source/Plugins; other minor fixes. Differential Revision: http://reviews.llvm.org/D13951 llvm-svn: 250925
* [LLDB] Insert names with same signo as alias instead of a new entryMohit K. Bhakkad2015-10-203-202/+198
| | | | | | | | Reviewers: clayborg, labath. Subscribers: jaydeep, dsanders, bhushan, sagar, nitesh.jain, emaste,lldb-commits. Differential Revision: http://reviews.llvm.org/D13646 llvm-svn: 250801
* [LLDB] Fix Clang-tidy modernize-use-override warnings in some headers in ↵Eugene Zelenko2015-10-1717-367/+375
| | | | | | | | source/Plugins/Process/Utility; other minor fixes. Differential Revision: http://reviews.llvm.org/D13830 llvm-svn: 250593
* Fix a misunderstanding of the ThreadPlan::OkayToDiscard flag in ↵Jim Ingham2015-10-121-9/+0
| | | | | | | | | | | | | InferiorCallPOSIX. It was set to true, but all plans run by RunThreadPlan need to have this set to false so they will return control to RunThreadPlan without consulting plans higher on the stack. Since this seems like a common error, I also modified RunThreadPlan to enforce this behavior. <rdar://problem/22543166> llvm-svn: 250084
* X86: Change FTAG register size in FXSAVE structureAbhishek Aggarwal2015-10-122-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: - Changed from 16 bits to 8 bits for Intel Architecture -- FXSAVE structure now conforms with the layout of FXSAVE area specified by IA Architecture Software Developer Manual - Modified Linux and FreeBSD specific files to support this change -- MacOSX already uses 8 bits for ftag register - Modified TestRegisters.py and a.cpp: -- Change allows 8 bit comparison of ftag values -- Change resolves Bug 24733: Removed XFAIL for Clang as the test works and passes for Clang compiler as well -- Change provides a Generic/Better way of testing Bug 24457 and Bug 25050 by using 'int3' inline assembly in inferior Signed-off-by: Abhishek Aggarwal <abhishek.a.aggarwal@intel.com> Reviewers: ovyalov, jingham, clayborg Subscribers: tfiala, emaste Differential Revision: http://reviews.llvm.org/D13587 llvm-svn: 250022
* Fix several issues around .ARM.exidx section handlingTamas Berghammer2015-10-021-10/+10
| | | | | | | | | | | | | | * Use .ARM.exidx as a fallback unwind plan for non-call site when the instruction emulation based unwind failed. * Work around an old compiler issue where the compiler isn't sort the entries in .ARM.exidx based on their address. * Fix unwind info parsing when the virtual file address >= 0x80000000 * Fix bug in unwind info parsing when neither lr nor pc is explicitly restored. Differential revision: http://reviews.llvm.org/D13380 llvm-svn: 249119
* Add support for .ARM.exidx unwind informationTamas Berghammer2015-09-301-8/+23
| | | | | | | | | .ARM.exidx/.ARM.extab sections contain unwind information used on ARM architecture from unwinding from an exception. Differential revision: http://reviews.llvm.org/D13245 llvm-svn: 248903
* Clean up register naming conventions inside lldb. Jason Molenda2015-09-1519-1988/+1263
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "gcc" register numbers are now correctly referred to as "ehframe" register numbers. In almost all cases, ehframe and dwarf register numbers are identical (the one exception is i386 darwin where ehframe regnums were incorrect). The old "gdb" register numbers, which I incorrectly thought were stabs register numbers, are now referred to as "Process Plugin" register numbers. This is the register numbering scheme that the remote process controller stub (lldb-server, gdbserver, core file support, kdp server, remote jtag devices, etc) uses to refer to the registers. The process plugin register numbers may not be contiguous - there are remote jtag devices that have gaps in their register numbering schemes. I removed all of the enums for "gdb" register numbers that we had in lldb - these were meaningless - and I put LLDB_INVALID_REGNUM in all of the register tables for the Process Plugin regnum slot. This change is almost entirely mechnical; the one actual change in here is to ProcessGDBRemote.cpp's ParseRegisters() which parses the qXfer:features:read:target.xml response. As it parses register definitions from the xml, it will assign sequential numbers as the eRegisterKindLLDB numbers (the lldb register numberings must be sequential, without any gaps) and if the xml file specifies register numbers, those will be used as the eRegisterKindProcessPlugin register numbers (and those may have gaps). A J-Link jtag device's target.xml does contain a gap in register numbers, and it only specifies the register numbers for the registers after that gap. The device supports many different ARM boards and probably selects different part of its register file as appropriate. http://reviews.llvm.org/D12791 <rdar://problem/22623262> llvm-svn: 247741
* Move RegisterContextPOSIX.h to FreeBSD subdirEd Maste2015-09-141-79/+0
| | | | | | It is now used only by the FreeBSD in-process ptrace implementation. llvm-svn: 247561
* Limit scope of RegisterContextPOSIX.h headerEd Maste2015-09-1415-16/+18
| | | | | | | | | | | | | | | RegisterContextPOSIX.h is poorly named and contains only the declaration of POSIXBreakpointProtocol, which is used for in-process live kernel debugging. It is now relevant only to FreeBSD. In source/Plugins/Process/Utility/RegisterContext*.h (after assorted rework and refactoring) it only served the purpose of #including other necessary headers as a side-effect. Remove it from them and just include the required headers directly. Differential Revision: http://reviews.llvm.org/D12830 llvm-svn: 247558
* Switch default disposition of realtime signalsPavel Labath2015-09-143-130/+130
| | | | | | | | | | | | | | | | | | | | | Summary: Realtime signals generally do not represent an error condition in an application but are more like a regular means of IPC. As such, we shouldn't interrupt an application whenever it recieves one. If any application will use these signals, it will probably use them a lot, rendering it's debugging tiresome if we stopped at every signal. Furthermore, these signals are likely to be used in a low level library, and the programmer may not even be aware of their presence. For these reasons, I am switching the default disposition of realtime signals on all supported platforms (i.e. Linux and Freebsd) to no-stop, no-notify. Any user still wishing to receive these signals can always change the default to suit his needs. Reviewers: ovyalov, emaste Subscribers: lldb-commits, emaste Differential Revision: http://reviews.llvm.org/D12795 llvm-svn: 247537
* Change the looping stack detection codeTamas Berghammer2015-09-091-14/+16
| | | | | | | | | | | In some special case (e.g. signal handlers, hand written assembly) it is valid to have 2 stack frame with the same CFA value. This CL change the looping stack detection code to report a loop only if at least 3 consecutive frames have the same CFA. Differential revision: http://reviews.llvm.org/D12699 llvm-svn: 247133
* Fix the handling of FPR offsets in Linux arm/aarch64 register contextsTamas Berghammer2015-09-071-1/+1
| | | | | | Differential revision: http://reviews.llvm.org/D12636 llvm-svn: 246959
* [cmake] Remove LLVM_NO_RTTI.Bruce Mitchener2015-09-031-2/+0
| | | | | | | | | | | | | | Summary: This doesn't exist in other LLVM projects any longer and doesn't do anything. Reviewers: chaoren, labath Subscribers: emaste, tberghammer, lldb-commits, danalbert Differential Revision: http://reviews.llvm.org/D12586 llvm-svn: 246749
* Handle DW_OP_GNU_addr_index in DWARF expressionsTamas Berghammer2015-08-251-2/+10
| | | | | | Differential revision: http://reviews.llvm.org/D12290 llvm-svn: 245932
* The llvm Triple for an armv6m now comes back as llvm::Triple::thumb.Jason Molenda2015-08-211-0/+4
| | | | | | | | | | | | | | This was breaking disassembly for arm machines that we force to be thumb mode all the time because we were only checking for llvm::Triple::arm. i.e. armv6m (ARM Cortex-M0) armv7m (ARM Cortex-M3) armv7em (ARM Cortex-M4) <rdar://problem/22334522> llvm-svn: 245645
* Remove unintentional ;'s.Jason Molenda2015-08-181-2/+2
| | | | llvm-svn: 245261
* [LLDB][MIPS] Fix offsets of all register sets and add MSA regset and FRE=1 ↵Sagar Thakur2015-08-1711-215/+769
| | | | | | | | | | | | | | | | mode support This patch : - Fixes offsets of all register sets for Mips. - Adds MSA register set and FRE=1 mode support for FP register set. - Separates lldb register numbers and register infos of freebsd/mips64 from linux/mips64. - Re-orders the register numbers of all kinds for mips to be consistent with freebsd order of register numbers. Reviewers: jaydeep, clayborg, jasonmolenda, ovyalov, emaste Subscribers: tberghammer, ovyalov, emaste, mohit.bhakkad, nitesh.jain, bhushan Differential: http://reviews.llvm.org/D10919 llvm-svn: 245217
* Update DynamicRegisterInfo::SetRegisterInfo to accept eh_frame registerJason Molenda2015-08-151-1/+7
| | | | | | | | numbers in the key name "ehframe" or "eh_frame" in addition to the deprecated "gcc" name (e.g. from a plugin.process.gdb-remote.target-definition-file python file). llvm-svn: 245151
* A messy bit of cleanup: Move towards more descriptive namesJason Molenda2015-08-1519-43/+42
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | for eh_frame and stabs register numberings. This is not complete but it's a step in the right direction. It's almost entirely mechanical. lldb informally uses "gcc register numbering" to mean eh_frame. Why? Probably because there's a notorious bug with gcc on i386 darwin where the register numbers in eh_frame were incorrect. In all other cases, eh_frame register numbering is identical to dwarf. lldb informally uses "gdb register numbering" to mean stabs. There are no official definitions of stabs register numbers for different architectures, so the implementations of gdb and gcc are the de facto reference source. There were some incorrect uses of these register number types in lldb already. I fixed the ones that I saw as I made this change. This commit changes all references to "gcc" and "gdb" register numbers in lldb to "eh_frame" and "stabs" to make it clear what is actually being represented. lldb cannot parse the stabs debug format, and given that no one is using stabs any more, it is unlikely that it ever will. A more comprehensive cleanup would remove the stabs register numbers altogether - it's unnecessary cruft / complication to all of our register structures. In ProcessGDBRemote, when we get register definitions from the gdb-remote stub, we expect to see "gcc:" (qRegisterInfo) or "gcc_regnum" (qXfer:features:read: packet to get xml payload). This patch changes ProcessGDBRemote to also accept "ehframe:" and "ehframe_regnum" from these remotes. I did not change GDBRemoteCommunicationServerLLGS or debugserver to send these new packets. I don't know what kind of interoperability constraints we might be working under. At some point in the future we should transition to using the more descriptive names. Throughout lldb we're still using enum names like "gcc_r0" and "gdb_r0", for eh_frame and stabs register numberings. These should be cleaned up eventually too. The sources link cleanly on macosx native with xcode build. I don't think we'll see problems on other platforms but please let me know if I broke anyone. llvm-svn: 245141
OpenPOWER on IntegriCloud