summaryrefslogtreecommitdiffstats
path: root/lldb/source/Plugins/ObjectFile
Commit message (Collapse)AuthorAgeFilesLines
...
* Move the code which knows how to get information about the sharedJason Molenda2016-07-291-63/+7
| | | | | | | | | | cache from ObjectFileMachO (very wrong place) to the DynamicLoader plugins (better place). Not much change to the code itself, although the old ObjectFileMachO method would try both the new dyld SPI and reading the dyld_all_image_infos structure. In the new methods, I've separated those into the appropriate DynamicLoader plugins. llvm-svn: 277088
* Fix a crash when an ELF section symbol have no nameTamas Berghammer2016-07-221-2/+4
| | | | llvm-svn: 276403
* Add support to get the shared cache information from the newJason Molenda2016-07-221-0/+27
| | | | | | | | | | | | | debugserver jGetSharedCacheInfo packet instead of reading the dyld internal data structures directly. This code is (currently) only used for ios native lldb's - I should really move this ObjectFileMachO::GetProcessSharedCacheUUID method somewhere else, it makes less and less sense being in the file reader. <rdar://problem/25251243> llvm-svn: 276369
* Typo corrections identified by codespellEd Maste2016-07-191-1/+1
| | | | | | | | | Submitted by giffunip@yahoo.com; I fixed a couple of nearby errors and incorrect changes in the patch. llvm.org/pr27634 llvm-svn: 275983
* Add oat symbolization support for odex filesTamas Berghammer2016-07-061-4/+5
| | | | | | Differential revision: http://reviews.llvm.org/D22040 llvm-svn: 274635
* Ignore oatdata and oatexec symbols more widelyTamas Berghammer2016-07-041-4/+4
| | | | | | | | | | | These are artifical symbols inside android oat files without any value for the user while causing a significant perfoamce hit inside the unwinder. We were already ignoring it inside system@framework@boot.oat bot they have to be ignored in every oat file. Considering that oat files are only used on android this have no effect on any other platfrom. llvm-svn: 274500
* Revert r273524, it may have been the cause of a linux testbot failureJason Molenda2016-06-231-3/+3
| | | | | | | | 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-231-3/+3
| | | | | | | | | 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
* Since our expression parser needs to locate areas of memory that are not in ↵Greg Clayton2016-06-092-1/+11
| | | | | | | | use when you have a process that can't JIT code, like core file debugging, the core file process plug-ins should be able to override the Process::GetMemoryRegionInfo(...) function. In order to make this happen, I have added permissions to sections so that we can know what the permissions are for a given section, and modified both core file plug-ins to override Process::GetMemoryRegionInfo() and answer things correctly. llvm-svn: 272276
* Small further refinement to the check in ObjectFileMachO::ParseSymtabJason Molenda2016-05-261-7/+9
| | | | | | | | | | | | | | | | | which looks for binaries missing an LC_FUNCTION_STARTS section because it was stripped/not emitted. If we see a normal user process binary (executable, dylib, framework, bundle) without LC_FUNCTION_STARTS, that is unusual and we should disallow instruction emulation because that binary has likely been stripped a lot. If this is a non-user process binary -- a kernel, a standalone bare-board binary, a kernel extension (kext) -- and there is no LC_FUNCTION_STARTS, we should not assume anything about the binary and allow instruction emulation as we would normally do. <rdar://problem/26453952> llvm-svn: 270818
* Ach, editing too many files at once. Make this file compile again.Jason Molenda2016-05-241-1/+1
| | | | llvm-svn: 270620
* In r268475 I made a change to ObjectFileMachO so that if it isJason Molenda2016-05-241-1/+4
| | | | | | | | | | | | | | | | missing an LC_FUNCTION_STARTS section, we assume it has been aggressively stripped (it is *very* unusual for anyone to strip LC_FUNCTION_STARTS) so we disable assembly instruction unwind plan creation. Kernel extensions (kexts) don't have LC_FUNCTION_STARTS, but we almost always have good symbol bounds just with the linker symbols. So add an exception to allow assembly instruction unwind plan creation for kexts even though they lack LC_FUNCTION_STARTS. <rdar://problem/26453952> llvm-svn: 270618
* [LLDB][MIPS] Fix floating point handling in case of thread step-outSagar Thakur2016-05-241-2/+34
| | | | | | | | | | | Patch by Nitesh Jain. Summary: These patch fix thread step-out for hard and soft float. Reviewers: jaydeep, bhushan, clayborg Differential Revision: http://reviews.llvm.org/D20416 llvm-svn: 270564
* Revert rL270207: "[LLDB][MIPS] Fix floating point handling in case of thread ↵Tamas Berghammer2016-05-201-34/+2
| | | | | | | | | | step-out" The CL causes a build breakage on platforms where sizeof(double) == sizeof(long double) and it incorrectly assumes that sizeof(double) and sizeof(long double) is the same on the host and the target. llvm-svn: 270214
* [LLDB][MIPS] Fix floating point handling in case of thread step-outSagar Thakur2016-05-201-2/+34
| | | | | | | | | | | Patch by Nitesh Jain. Summary: These patch fix thread step-out for hard and soft float. Reviewers: clayborg, bhushan, jaydeep Subscribers: mohit.bhakkad, sagar, sdardis Differential: D20416 llvm-svn: 270207
* second pass over removal of Mutex and ConditionSaleem Abdulrasool2016-05-193-4/+4
| | | | llvm-svn: 270024
* remove use of Mutex in favour of std::{,recursive_}mutexSaleem Abdulrasool2016-05-185-19/+18
| | | | | | | | | | 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
* [LLDB][MIPS] Setting appropriate ArchSpec::m_flags based on ABISagar Thakur2016-05-111-8/+21
| | | | | | | | | | | Patch by Nitesh Jain. Summary: The ArchSpec::m_flags will be set based on ELF flag ABI. Reviewers: ovyalov, clayborg Subscribers: lldb-commits, mohit.bhakkad, sagar, jaydeep, bhushan Differential: D18858 llvm-svn: 269181
* Add a way for an ObjectFile to indicate that assembly emulationJason Molenda2016-05-042-2/+28
| | | | | | | | | | | | | | | | | | | | | should not be used for this module -- for use when an ObjectFile knows that it does not have meaningful or accurate function start addresses. More commonly, it is not clear that function start addresses are missing in a module. There are certain cases on Mac OS X where we can tell that a Mach-O binary has been stripped of this essential information, and the unwinder can end up emulating many megabytes of instructions for a single "function" in the binary. When a Mach-O binary is missing both an LC_FUNCTION_STARTS load command (very unusual) and an eh_frame section, then we will assume it has also been stripped of symbols and that instruction emulation will not be useful on this module. <rdar://problem/25988067> llvm-svn: 268475
* rL267291: Architecture change to thumb on parsing arm.attributes causes ↵Omair Javaid2016-04-261-13/+0
| | | | | | | | | | regression. Remove case handling elf arm attribute Tag_THUMB_ISA_use and setting architecture to thumb. Differential revision: http://reviews.llvm.org/D19520 llvm-svn: 267550
* Fix ARM attribute parsing for Android after rL267291Tamas Berghammer2016-04-251-6/+3
| | | | | | Differential revision: http://reviews.llvm.org/D19480 llvm-svn: 267422
* Handle invalid values of PLT entry size generated by linkerOmair Javaid2016-04-251-1/+4
| | | | | | | | Make sure we figure out correct plt entry field in case linker has generated a small value below realistic entry size like 4 bytes or below. Differential revision: http://reviews.llvm.org/D19252 llvm-svn: 267405
* Fix unwind failures when PC points beyond the end of a functionUlrich Weigand2016-04-241-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* ObjectFile: parse EABI AttributesSaleem Abdulrasool2016-04-232-0/+104
| | | | | | | | This adds basic parsing of the EABI attributes section. This section contains additional information about the target for which the file was built. Attempt to infer additional architecture information from that section. llvm-svn: 267291
* Find .plt section in object files generated by recent ldUlrich Weigand2016-04-141-5/+5
| | | | | | | | | | | | | | | | | | | | Code in ObjectFileELF::ParseTrampolineSymbols assumes that the sh_info field of the .rel(a).plt section identifies the .plt section. However, with recent GNU ld this is no longer true. As a result of this: https://sourceware.org/bugzilla/show_bug.cgi?id=18169 in object files generated with current linkers the sh_info field of .rel(a).plt now points to the .got.plt section (or .got on some targets). This causes LLDB to fail to identify any PLT stubs, causing a number of test case failures. This patch changes LLDB to simply always look for the .plt section by name. This should be safe across all linkers and targets. Differential Revision: http://reviews.llvm.org/D18973 llvm-svn: 266316
* Support Linux on SystemZ as platformUlrich Weigand2016-04-141-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* Implement `target modules dump objfile`Adrian McCarthy2016-04-041-0/+16
| | | | | | Differential Revision: http://reviews.llvm.org/D18464 llvm-svn: 265349
* Implement ObjectFilePECOFF::GetEntryPointAddress.Stephane Sezer2016-03-232-3/+24
| | | | | | | | | | Reviewers: zturner, clayborg Subscribers: lldb-commits Differential Revision: http://reviews.llvm.org/D17970 llvm-svn: 264173
* Allow any build-id length between 4 and 20 bytes inclusiveEd Maste2016-03-141-2/+3
| | | | | | | | | | | | Build-id support is being added to lld and by default it may produce a 64-bit build-id. Prior to this change lldb would reject such a build-id. However, it then falls back to a 4-byte crc32, which is a poorer quality identifier. Differential Revision: http://reviews.llvm.org/D18096 llvm-svn: 263432
* Update the on-device arm specific code to match the API changesJason Molenda2016-03-011-5/+5
| | | | | | | that happened in other parts of this file so it builds cleanly for arm again. llvm-svn: 262300
* Fix all of the unannotated switch cases to annotate the fall through or do ↵Greg Clayton2016-02-261-0/+1
| | | | | | the right thing and break. llvm-svn: 261950
* Add support for handling absolute symbols in ELFTamas Berghammer2016-02-252-24/+45
| | | | | | | | | | | | | | | Most address represented in lldb as section plus offset and handling of absolute addresses is problematic in several location because of lack of necessary information (e.g. Target) or because of performance issues. This CL change the way ObjectFileELF handle the absolute symbols with creating a pseudo section for each symbol. With this change all existing code designed to work with addresses in the form of section plus offset will work with absolute symbols as well. Differential revision: http://reviews.llvm.org/D17450 llvm-svn: 261859
* Improve the handling of missing elf symtab and missing symbol sizesTamas Berghammer2016-02-183-57/+66
| | | | | | | | | | | | | | | * Generate artificial symbol names from eh_fame during symbol parsing so these symbols are already present when we calcualte the size of the symbols where 0 is specified. * Fix symbol size calculation for the last symbol in the file where it have to last until the end of the parent section. This is the re-commit of the original change after fixing some test failures on OSX. Differential revision: http://reviews.llvm.org/D16996 llvm-svn: 261205
* Add -Wimplicit-fallthrough command line option to clang inJason Molenda2016-02-161-2/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | the xcode project file to catch switch statements that have a case that falls through unintentionally. Define LLVM_FALLTHROUGH to indicate instances where a case has code and intends to fall through. This should be in llvm/Support/Compiler.h; Peter Collingbourne originally checked in there (r237766), then reverted (r237941) because he didn't have time to mark up all the 'case' statements that were intended to fall through. I put together a patch to get this back in llvm http://reviews.llvm.org/D17063 but it hasn't been approved in the past week. I added a new lldb-private-defines.h to hold the definition for now. Every place in lldb where there is a comment that the fall-through is intentional, I added LLVM_FALLTHROUGH to silence the warning. I haven't tried to identify whether the fallthrough is a bug or not in the other places. I haven't tried to add this to the cmake option build flags. This warning will only work for clang. This build cleanly (with some new warnings) on macosx with clang under xcodebuild, but if this causes problems for people on other configurations, I'll back it out. llvm-svn: 260930
* Revert "Improve the handling of missing elf symtab and missing symbol sizes"Tamas Berghammer2016-02-103-66/+57
| | | | | | | | This reverts commit 252dda67782f2cbf838e375bce21ed4191f6d9ce. The commit caused several test failure on the OSX build bot. llvm-svn: 260377
* Improve the handling of missing elf symtab and missing symbol sizesTamas Berghammer2016-02-103-57/+66
| | | | | | | | | | | | * Generate artificial symbol names from eh_fame during symbol parsing so these symbols are already present when we calcualte the size of the symbols where 0 is specified. * Fix symbol size calculation for the last symbol in the file where it have to last until the end of the parent section. Differential revision: http://reviews.llvm.org/D16996 llvm-svn: 260369
* Add support to detect arm hard float ABI based binaries for ABISysV_armOmair Javaid2016-02-051-0/+9
| | | | | | | | This patch adds logic to detect if underlying binary is using arm hard float abi and use that information while handling return values in ABISysV_arm. Differential revision: http://reviews.llvm.org/D16627 llvm-svn: 259885
* Revert "[NFC] Cleanup RangeMap.h"Todd Fiala2016-02-021-175/+0
| | | | | | | This reverts commit r259538. Caused 92 test failures on the OS X testbot. llvm-svn: 259556
* [NFC] Cleanup RangeMap.hTamas Berghammer2016-02-021-0/+175
| | | | | | | | | | | | | | | | | The file contained very similar 4 implementation of the same data structure with a lot of duplicated code and some minor API differences. This CL refactor the class to eliminate the duplicated codes and to unify the APIs. RangeMap.h also contained a class called AddressDataArray what have very little added functionality over an std::vector and used only by ObjectFileMacO The CL moves the class to ObjectFileMachO.cpp as it isn't belongs into RangeMap.h and shouldn't be used in new places anyway because of the little added functionality. Differential revision: http://reviews.llvm.org/D16769 llvm-svn: 259538
* Remove autoconf support from source directories.Eugene Zelenko2016-01-284-56/+0
| | | | | | Differential revision: http://reviews.llvm.org/D16662 llvm-svn: 259098
* Set symbol types for function symbols loaded from PE/COFFAdrian McCarthy2016-01-262-6/+22
| | | | | | | | | | | | | | | | This fixes the regression of several tests on Windows after rL258621. The root problem is that ObjectFilePECOFF was not setting type information for the symbols, and the new CL rejects symbols without type information, breaking functionality like thread step-over. The fix sets the type information for functions (and creates a TODO for other types). Along the way, I fixed some typos and formatting that made the code I was debugging harder to understand. In the long run, we should consider replacing most of ObjectFilePECOFF with the COFF parsing code from LLVM. Differential Revision: http://reviews.llvm.org/D16563 llvm-svn: 258758
* Add CalculateSymbolSizes in ObjectFilePECOFF::GetSymtab to ensure that ↵Adrian McCarthy2016-01-211-0/+1
| | | | | | | | | | (nearly) all the symbols have sizes. This fixes the `thread step-over` regression exposed by http://reviews.llvm.org/D16186 , which depends on the symbols having actual sizes. Nine tests on Windows had started failing as a result. They all work again with this fix. Differential Revision: http://reviews.llvm.org/D16415 llvm-svn: 258429
* When ObjectFileMachO reads a Mach-O file for a 32-bit arm cpu,Jason Molenda2016-01-211-3/+16
| | | | | | | | | | | | | | | | | | | | | | set the triple's "vendor" field to Apple. We don't want to assume a vendor of Apple for all Mach-O files - this breaks x86_64 EFI debugging where they put non-Apple binaries in a Mach-O format for ease of handling. But on armv7, Apple's ABI always uses r7 as the frame pointer register; if we don't set the Vendor field to Apple, we can pick up a generic armv7 ABI where the fp is r11 (or r7 for thumb) which breaks backtracing altogether. Greg is reluctant for us to make any assumptions about the Vendor here, but we'll see how this shakes out. It's such a big problem on armv7 if we don't know this is using the Apple ABI that it's worth trying this approach. <rdar://problem/22137561> llvm-svn: 258387
* Some 32-bit arm corefiles on darwin may have their general purposeJason Molenda2016-01-201-1/+2
| | | | | | | | | | 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 Bug 25338Ravitheja Addepally2016-01-192-14/+63
| | | | | | | | | | | | | | | | Summary: The issue arises because LLDB is not able to read the vdso library correctly. The fix adds memory allocation callbacks to allocate sufficient memory in case the requested offsets don't fit in the memory buffer allocated for the ELF. Reviewers: lldb-commits, clayborg, deepak2427, ovyalov, labath, tberghammer Differential Revision: http://reviews.llvm.org/D16107 llvm-svn: 258122
* Unconditionally accept symbol sizes from elfTamas Berghammer2016-01-191-2/+10
| | | | | | | | | | | | | | | | | | | The ELF symbol table always contain the size of the symbols so we don't have to try to guess them based on the address of the next symbol (it is needed for mach-o). The change fixes an issue when a symbol is removed after a 0 size symbol (e.g. because the second one is not public) what previously caused the symbol lookup algorithm to end up with showing the 0 size symbol even for the later addresses (what are not part of any symbol). That symbol lookup error can confuse the user and also confuses the current stack unwinder. Re-commit this CL after fixing the issue with gcc-4.9.2 on i386 Linux. Differential revision: http://reviews.llvm.org/D16186 llvm-svn: 258113
* Update for llvm change. NFC.Rafael Espindola2016-01-182-5/+5
| | | | llvm-svn: 258080
* Revert "Unconditionally accept symbol sizes from elf"Tamas Berghammer2016-01-181-4/+2
| | | | | | | | It causes issues for i386 when compiling with gcc-4.9.2 This reverts commit e248214a3eab8e244095f97d1996c991cb988cc4. llvm-svn: 258043
* Unconditionally accept symbol sizes from elfTamas Berghammer2016-01-181-2/+4
| | | | | | | | | | | | | | | | | The ELF symbol table always contain the size of the symbols so we don't have to try to guess them based on the address of the next symbol (it is needed for mach-o). The change fixes an issue when a symbol is removed after a 0 size symbol (e.g. because the second one is not public) what previously caused the symbol lookup algorithm to end up with showing the 0 size symbol even for the later addresses (what are not part of any symbol). That symbol lookup error can confuse the user and also confuses the current stack unwinder. Differential revision: http://reviews.llvm.org/D16186 llvm-svn: 258040
* [LLDB][MIPS] Fix rL255619: mips 3, 4 and 5 are 64 bit archsMohit K. Bhakkad2016-01-121-3/+3
| | | | llvm-svn: 257448
OpenPOWER on IntegriCloud