summaryrefslogtreecommitdiffstats
path: root/lldb/source/Core/ArchSpec.cpp
Commit message (Collapse)AuthorAgeFilesLines
* Fix arm-linux-gnueabi regression due to rL267291Omair Javaid2016-04-261-1/+5
| | | | | | | | | | | | rL267291 introduces a lot regression on arm-linux LLDB testsuite. This patch fixes half of them. I am merging it under already revied android counterpart. Another patch fixing rest of the issue will follow this commit. Differential revision: http://reviews.llvm.org/D19480 llvm-svn: 267508
* Fix ARM attribute parsing for Android after rL267291Tamas Berghammer2016-04-251-8/+23
| | | | | | Differential revision: http://reviews.llvm.org/D19480 llvm-svn: 267422
* 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
* Remove unintentional returnBhushan D. Attarde2016-04-111-1/+0
| | | | llvm-svn: 265931
* Print environment when dumping arch tripleStephane Sezer2016-04-051-0/+4
| | | | | | | | | | | | | | Summary: Print environment from triple if it exists. Reviewers: tfiala, clayborg Subscribers: lldb-commits, sas Differential Revision: http://reviews.llvm.org/D18620 Change by Francis Ricci <fjricci@fb.com> llvm-svn: 265420
* Consolidate the knowledge of what arm cores are always executingJason Molenda2016-04-051-0/+36
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | in thumb mode into one method in ArchSpec, replace checks for specific cores in the disassembler with calls to this. Also call this from the arm instruction emulation code. The determination of whether a given ArchSpec is thumb-only is still a bit of a hack, but at least the hack is consolidated into a single place. In my original version of this patch http://reviews.llvm.org/D13578 I was calling into llvm's feature arm feature tables to make this determination, like #include "llvm/Support/TargetRegistry.h" #include "llvm/MC/MCSubtargetInfo.h" #include "llvm/../../lib/Target/ARM/ARMGenRegisterInfo.inc" #include "llvm/../../lib/Target/ARM/ARMFeatures.h" [...] std::string triple (GetTriple().getTriple()); const char *cpu = ""; const char *features_str = ""; const llvm::Target *curr_target = llvm::TargetRegistry::lookupTarget(triple.c_str(), Error); std::unique_ptr<llvm::MCSubtargetInfo> subtarget_info_up (curr_target->createMCSubtargetInfo(triple.c_str(), cpu, features_str)); if (subtarget_info_up->getFeatureBits()[llvm::ARM::FeatureNoARM]) { return true; } but those tables are post-llvm-build generated and linking against them for all of our different build system methods was a big hiccup that I haven't had time to revisit convincingly. I'll keep that reviews.llvm.org patch around to remind myself that I need to take another run at linking against the necessary tables again in llvm. <rdar://problem/23022803> llvm-svn: 265377
* Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; ↵Eugene Zelenko2016-03-021-33/+26
| | | | | | other minor fixes. llvm-svn: 262441
* Fix all of the unannotated switch cases to annotate the fall through or do ↵Greg Clayton2016-02-261-0/+3
| | | | | | the right thing and break. llvm-svn: 261950
* [LLDB][MIPS] Provide CPU string to compiler for appropriate code generation ↵Bhushan D. Attarde2016-02-181-0/+50
| | | | | | | | | | | | | | | for MIPS SUMMARY: This patch implements ArchSpec::GetClangTargetCPU() that provides string representing current architecture as a target CPU. This string is then passed to tools like clang so that they generate correct code for that target. Reviewers: clayborg, zturner Subscribers: mohit.bhakkad, sagar, jaydeep, lldb-commits Differential Revision: http://reviews.llvm.org/D17022 llvm-svn: 261206
* Add -Wimplicit-fallthrough command line option to clang inJason Molenda2016-02-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | 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
* A little more careful handling of platforms and unspecified unknownJason Molenda2015-11-061-43/+74
| | | | | | | vendors & oses, especially on Apple, to handle the new environment where we have more than macosx or ios (now we have watchos and tvos). llvm-svn: 252264
* ArchSpec: fix unintentional promotion of unspecified unknowns to specified ↵Todd Fiala2015-10-131-2/+17
| | | | | | | | | | | | | | | | | | | | | unknowns * ArchSpec::MergeFrom() would erroneously promote an unspecified unknown to a specified unknown when both the ArchSpec and the merged in ArchSpec were both unspecified unknowns. This no longer happens, which fixes issues with global module cache lookup in some situations. * Added ArchSpec::DumpTriple(Stream&) that now properly prints unspecified unknowns as '*' and specified unknows as 'unknown'. This makes it trivial to tell the difference between the two. Converted printing code over ot using DumpTriple() rather than building from scratch. * Fixed up a couple places that were not guaranteeing that an unspecified unknown was recorded as such. llvm-svn: 250253
* Re-commit the (fixed) changes from r248985 which were reverted by PavelJason Molenda2015-10-081-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
* [LLDB][MIPS] Added support for the debugging of N32/O32 applications on ↵Mohit K. Bhakkad2015-09-091-1/+9
| | | | | | | | | | | | MIPS64 target. Patch by Nitesh Jain Reviewers: clayborg, ovyalov. Subscribers: jaydeep, bhushan, mohit.bhakkad, sagar, nitesh.jain, lldb-commits. Differential Revision: http://reviews.llvm.org/D12671 llvm-svn: 247134
* Fix compiler warning in ArchSpecPavel Labath2015-07-161-10/+10
| | | | llvm-svn: 242397
* [LLDB][MIPS] Detect MIPS application specific extensions like micromipsJaydeep Patil2015-07-161-25/+32
| | | | | | | | | | | | | | SUMMARY: The patch detects MIPS application specific extensions (ASE) like micromips by reading ELF header.e_flags and SHT_MIPS_ABIFLAGS section. MIPS triple does not contain ASE information like micromips, mips16, DSP, MSA etc. These can be read from header.e_flags or SHT_MIPS_ABIFLAGS section. Reviewers: clayborg Subscribers: mohit.bhakkad, sagar, lldb-commits Differential Revision: http://reviews.llvm.org/D11133 llvm-svn: 242381
* [LLDB][MIPS] Add mips cores in cores_match () in ArchSpecSagar Thakur2015-07-131-3/+93
| | | | | | | | | | | | | | | This patch: - Allows mips32 cores to match with any mips32/mips64 cores. - Allows mips32r2 cores to match with core only up-to mips32r2/mips64r2. - Allows mips32r3 cores to match with core only up-to mips32r3/mips64r3. - Allows mips32r5 cores to match with core only up-to mips32r3/mips64r5. - Allows mips32r6 core to match with only mips32r6/mips64r6 or mips32/mips64. Reviewers: emaste, jaydeep, clayborg Subscribers: mohit.bhakkad, nitesh.jain, bhushan, lldb-commits Differential Revision: http://reviews.llvm.org/D10921 llvm-svn: 242016
* Leave OS as unspecified unknown if it isn't specified in the ELF fileTamas Berghammer2015-07-071-11/+6
| | | | | | | | | This is the redone of r238623 what was reverted with the refactor in r239148. Differential revision: http://reviews.llvm.org/D10957 llvm-svn: 241569
* Mark armv7em and armv7m as compatible architectures.Jason Molenda2015-06-251-1/+31
| | | | | | <rdar://problem/21244671> llvm-svn: 240713
* Fix the lldb build for the EM_486 change.Rafael Espindola2015-06-191-1/+1
| | | | llvm-svn: 240138
* Improve OSType initialization in elf object file's arch_specEd Maste2015-06-051-1/+18
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Setting the OSType in the ArchSpec triple is needed to correctly setup up the register context plugin. ArchSpec::SetArchitecture, for Mach-O only, sets the OSType. For ELF it was left to the ObjectFileELF to fill in the missing OSType. This change moves the ObjectFileELF logic into ArchSpec. A new optional 'os' parameter has been added to SetArchitecture. For ELF, this value is the from the ELF header.e_ident[EI_OSABI]. The default value is 0 or ELFOSABI_NONE. The real work of determining the OSType was done by the ObjectFileELF helper function GetOsFromOSABI. This logic has been moved SetArchitecture. GetOsFromOSABI has been commented as being deprectated. It is left in to support asserts. For ELF the vendor value returned from SetArchitecture should be UnknownVendor. An unneeded resetting in ObjectFileELF has been removed and replaced with an assert. This fixes a problem reading a core file on FreeBSD/ARM because the spec triple was arm-unknown-unknown. Patch by Tom Rix. Differential Revision: http://reviews.llvm.org/D9292 llvm-svn: 239148
* [MIPS][lldb-server] Add 32-bit register context and read/write FP registers ↵Sagar Thakur2015-06-031-10/+40
| | | | | | | | | | | | | on mips64 - Added support for read/write FP registers in FR1 mode. - Added 32 bit register context for mips32. Reviewers: clayborg, tberghammer, jaydeep Subscribers: emaste, nitesh.jain, bhushan, mohit.bhakkad, lldb-commits Differential Revision: http://reviews.llvm.org/D10029 llvm-svn: 238914
* Leave OS type and vendor as unspecified unknowns.Oleksiy Vyalov2015-05-291-6/+0
| | | | | | http://reviews.llvm.org/D10080 llvm-svn: 238623
* [LLDB][MIPS] Add MIPS32 and MIPS64 core revisionsMohit K. Bhakkad2015-04-231-4/+35
| | | | | | | | | | | | | | | Patch by Jaydeep Patil Added MIPS32 and MIPS64 core revisions. This would be followed by register context and emulate-instruction for MIPS32. DYLDRendezvous.cpp: On Linux link map struct does not contain extra load offset field. Reviewers: clayborg Subscribers: bhushan, mohit.bhakkad, sagar, lldb-commits. Differential Revision: http://reviews.llvm.org/D9190 llvm-svn: 235574
* Fix type detection for 'char' variablesTamas Berghammer2015-03-311-0/+26
| | | | | | | | | | | | A char can have signed and unsigned encoding but previously lldb always assumed it is signed. This CL adds a logic to detect the encoding of 'char' types based on the default encoding on the target architecture. It fixes variable printing and expression evaluation on architectures where 'char' is signed by default. Differential revision: http://reviews.llvm.org/D8636 llvm-svn: 233682
* Move some functions from source/lldb.cpp to Utility.Zachary Turner2015-03-181-1/+3
| | | | | | | | | | Specifically, there were some functions for converting enums to strings and a function for matching a string using a specific matching algorithm. This moves those functions to more appropriate headers in lldb/Utility and updates references to include the new headers. llvm-svn: 232673
* [MIPS] - Register Context for MIPS64Mohit K. Bhakkad2015-03-171-1/+3
| | | | | | | | | | | | | | | | Patch by Jaydeep Patil Summery: 1. Add MIPS variants by parsing e_flags of the ELF 2. Create RegisterInfoInterface and RegisterContext for MIPS64 and MIPS64EL Reviewers: clayborg Subscribers: tberghammer, bhushan, mohit.bhakkad, sagar Differential Revision: http://reviews.llvm.org/D8166 llvm-svn: 232467
* Don't stomp the triple when loading a PECOFF target.Zachary Turner2015-01-221-0/+13
| | | | | | | | | | | | | | | | | | | | | When you create a target, it tries to look for the platform's list of supported architectures for a match. The match it finds can contain specific triples, like i386-pc-windows-msvc. Later, we overwrite this value with the most generic triple that can apply to any platform with COFF support, causing some of the fields of the triple to get overwritten. This patch changes the behavior to only merge in values from the COFF triple if the fields of the matching triple were unknown/unspecified to begin with. This fixes load address resolution on Windows, since it enables the DynamicLoaderWindows to be used instead of DynamicLoaderStatic. Reviewed by: Greg Clayton Differential Revision: http://reviews.llvm.org/D7120 llvm-svn: 226849
* 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
* 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
* 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
* 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
* Very minimal support 24-bit kalimbas. Vanilla "memory read" for data sectionsMatthew Gardiner2014-09-291-18/+5
| | | | | | | | | | | works, as do breakpoints, run and pause, display zeroth frame. See http://reviews.llvm.org/D5503 for a fuller description of the changes in this commit. llvm-svn: 218596
* Add an interface on ArchSpec to provide lldb client codeMatthew Gardiner2014-09-011-0/+34
| | | | | | | with a mechanism to query if the current target architecture has non 8-bit bytes. llvm-svn: 216867
* lldb - towards AArch64 being recognised as platform architectureTodd Fiala2014-08-281-0/+36
| | | | | | | | See http://reviews.llvm.org/D4381. Change by Paul Osmialowski. llvm-svn: 216668
* Add support for kalimba architecture variants 3, 4 and 5.Matthew Gardiner2014-08-271-2/+18
| | | | | | | | Add entries to core_definitions and elf_arch_entries for those variants. Select the subtype for the variant by parsing the e_flags field of the elf header. llvm-svn: 216541
* Move Host::GetArchitecture to HostInfo::GetArchitecture.Zachary Turner2014-08-201-7/+8
| | | | | | | | As a side effect, this patch also eliminates all of the preprocessor conditionals previously used to implement GetArchitecture(). llvm-svn: 216074
* add missing break. Fix CID 1229446 & 1203680Sylvestre Ledru2014-08-181-3/+5
| | | | llvm-svn: 215894
* When constructing an ArchSpec from a MachO cpu type and subtype, don't set ↵Greg Clayton2014-07-291-0/+9
| | | | | | | | the OS for x86_64 and x86 in case the binary ends up being for macosx or ios. <rdar://problem/17819272> llvm-svn: 214188
* Fix supported architectures on PlatformWindows.Zachary Turner2014-07-281-2/+6
| | | | | | | | | | i386, i486, i486sx, and i686 are all indistinguishable as far as PE/COFF files are concerned. This patch adds support for all of these architectures to PlatformWindows. Differential Revision: http://reviews.llvm.org/D4658 llvm-svn: 214092
* Fix the MSVC build. MSVC does not support constexpr.Zachary Turner2014-07-281-1/+1
| | | | llvm-svn: 214091
* Make sure we don't crash if someone (E.G.) comments out on entry from ↵Greg Clayton2014-07-231-6/+11
| | | | | | | | | | g_core_definitions[] without removing the ArchSpec::Core enumeration when submitting from source. We now catch the issue with a static_assert() at compile time and use llvm::array_lengthof(g_core_definitions) as well. <rdar://problem/17767541> llvm-svn: 213778
* Update lldb to track recent Triple arm64 enum removal and collapse into aarch64.Todd Fiala2014-07-231-2/+2
| | | | | | | | | | | 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
* Add kalimba as a platform.Todd Fiala2014-07-161-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | This change comprises of additions and some minor changes in order that "kalimba" is listed as a supported platform and that debugging any kalimbas results in PlatformKalimba being associated with the target. The changes are as follows: * The PlatformKalimba implementation itself * A tweak to ArchSpec * .note parsing for Kalimba in ObjectFileELF.cpp * Plugin registration * Makefile additions Change by Matthew Gardiner Minor tweak for cmake and Xcode by Todd Fiala Tested: Ubuntu 14.04 x86_64, clang 3.5-built lldb, all tests pass. MacOSX 10.9.4, Xcode 6.0 Beta 1-built lldb, all tests pass. llvm-svn: 213158
* lldb.LLDB_ARCH_DEFAULT now works correctly on Macs with haswell enabled kernels.Greg Clayton2014-07-141-0/+9
| | | | | | <rdar://problem/17604133> llvm-svn: 213004
* Allow generic ARM cores to match any more specific ARM architecture.Greg Clayton2014-07-121-1/+9
| | | | | | <rdar://problem/15932248> llvm-svn: 212863
* Cleanup the iOS simulator code.Greg Clayton2014-07-101-27/+4
| | | | | | | | | | | Fixes include: - Don't say that "<arch>-apple-ios" is compatible with "<arch>-apple-macosx" - Fixed DynamicLoaderMacOSXDYLD so specify an architecture that was converted solely from a cputype and subtype, just specify the file + UUID. - Fixed PlatformiOSSimulator::GetSupportedArchitectureAtIndex() so it returns the correct archs - Fixed SymbolFileDWARFDebugMap to load .o files correctly by just specifying the architecture without the vendor and OS now that "<arch>-apple-ios" is not compatible with "<arch>-apple-macosx" so we can load .o files correctly for DWARF with debug map - Fixed the coded in TargetList::CreateTarget() so it does the right thing with an underspecified triple where just the arch is specified. llvm-svn: 212783
* Add Kalimba support to ArchSpec.Todd Fiala2014-07-011-2/+6
| | | | | | | | | See http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140630/011508.html for more details. Change by Matthew Gardiner. llvm-svn: 212145
* lldb: remove adhoc implementation of array_sizeofSaleem Abdulrasool2014-06-271-5/+5
| | | | | | | | 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
* iOS simulator cleanup to make sure we use "*-apple-ios" for iOS simulator ↵Greg Clayton2014-05-291-4/+28
| | | | | | | | | | | | | | | | | | apps and binaries. Changes include: - ObjectFileMachO can now determine if a binary is "*-apple-ios" or "*-apple-macosx" by checking the min OS and SDK load commands - ArchSpec now says "<arch>-apple-macosx" is equivalent to "<arch>-apple-ios" since the simulator mixes and matches binaries (some from the system and most from the iOS SDK). - Getting process inforamtion on MacOSX now correctly classifies iOS simulator processes so they have "*-apple-ios" architectures in the ProcessInstanceInfo - PlatformiOSSimulator can now list iOS simulator processes correctly instead of showing nothing by using: (lldb) platform select ios-simulator (lldb) platform process list - debugserver can now properly return "*-apple-ios" for the triple in the process info packets for iOS simulator executables - GDBRemoteCommunicationClient now correctly passes along the triples it gets for process info by setting the OS in the llvm::Triple correctly <rdar://problem/17060217> llvm-svn: 209852
OpenPOWER on IntegriCloud