maxjhandsome
/
llvm-project
forked from OSchip/llvm-project
1
0
Fork 0
Code Issues Pull Requests Packages Releases Wiki Activity
llvm-project/lldb/source/Core/ArchSpec.cpp

1670 lines
59 KiB
C++
Raw Normal View History

Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//===-- ArchSpec.cpp --------------------------------------------*- C++ -*-===//
//
// The LLVM Compiler Infrastructure
//
// This file is distributed under the University of Illinois Open Source
// License. See LICENSE.TXT for details.
//
//===----------------------------------------------------------------------===//
#include "lldb/Core/ArchSpec.h"
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes. llvm-svn: 262441
2016-03-02 09:09:03 +08:00
// C Includes
// C++ Includes
#include <cerrno>
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
#include <cstdio>
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
#include <string>
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes. llvm-svn: 262441
2016-03-02 09:09:03 +08:00
// Other libraries and framework includes
lldb: remove adhoc implementation of array_sizeof 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
2014-06-27 13:17:41 +08:00
#include "llvm/ADT/STLExtras.h"
Plugins/ObjectFile/PECOFF: Use enums from LLVM, and don't use Mach-O definitions. Since I renamed most of the LLVM Mach-O enums in r189314, I had to go fix LLDB to use the new names. While I was here, I decided that a COFF plugin really shouldn't be using Mach-O enums. llvm-svn: 189316
2013-08-27 13:04:33 +08:00
#include "llvm/Support/COFF.h"
Made lldb_private::ArchSpec more generic so that it can take a mach-o cpu type and sub-type, or an ELF e_machine value. Also added a generic CPU type to the arch spec class so we can have a single arch definition that the LLDB core code can use. Previously a lot of places in the code were using the mach-o definitions from a macosx header file. Switches over to using "llvm/Support/MachO.h" for the llvm::MachO::XXX for the CPU types and sub types for mach-o ArchSpecs. Added "llvm/Support/ELF.h" so we can use the "llvm::ELF::XXX" defines for the ELF ArchSpecs. Got rid of all CPU_TYPE_ and CPU_SUBTYPE_ defines that were previously being used in LLDB. llvm-svn: 105806
2010-06-11 11:25:34 +08:00
#include "llvm/Support/ELF.h"
ArchSpec: Do not depend on Host::GetArchitecture. The major issue this patch solves is that ArchSpec::SetTriple no longer depends on the implementation of Host::GetArchitecture. On linux, Host::GetArchitecture calls ArchSpec::SetTriple, thus blowing the stack. A second smaller point is that SetTriple now defaults to Host defined components iff all OS, vendor and environment fields are not set. llvm-svn: 126403
2011-02-25 03:13:58 +08:00
#include "llvm/Support/Host.h"
Move some functions from source/lldb.cpp to Utility. 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
2015-03-19 05:31:45 +08:00
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes. llvm-svn: 262441
2016-03-02 09:09:03 +08:00
// Project includes
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
#include "Plugins/Process/Utility/ARMDefines.h"
#include "Plugins/Process/Utility/InstructionUtils.h"
Added the ability to set the architecture from two numbers that represent the mach-o CPU type and subtype in the format "%u-%u" or "%u.%u". This can of course be followed by vendor and OS. llvm-svn: 161465
2012-08-08 09:19:34 +08:00
#include "lldb/Core/RegularExpression.h"
Move Host::GetArchitecture to HostInfo::GetArchitecture. As a side effect, this patch also eliminates all of the preprocessor conditionals previously used to implement GetArchitecture(). llvm-svn: 216074
2014-08-21 00:42:51 +08:00
#include "lldb/Core/StringList.h"
Made lldb_private::ArchSpec contain much more than just an architecture. It now, in addition to cpu type/subtype and architecture flavor, contains: - byte order (big endian, little endian) - address size in bytes - llvm::Triple for true target triple support and for more powerful plug-in selection. llvm-svn: 125602
2011-02-16 05:59:32 +08:00
#include "lldb/Host/Endian.h"
Move Host::GetArchitecture to HostInfo::GetArchitecture. As a side effect, this patch also eliminates all of the preprocessor conditionals previously used to implement GetArchitecture(). llvm-svn: 216074
2014-08-21 00:42:51 +08:00
#include "lldb/Host/HostInfo.h"
Modified the ArchSpec to take an optional "Platform *" when setting the triple. This allows you to have a platform selected, then specify a triple using "i386" and have the remaining triple items (vendor, os, and environment) set automatically. Many interpreter commands take the "--arch" option to specify an architecture triple, so now the command options needed to be able to get to the current platform, so the Options class now take a reference to the interpreter on construction. Modified the build LLVM building in the Xcode project to use the new Xcode project level user definitions: LLVM_BUILD_DIR - a path to the llvm build directory LLVM_SOURCE_DIR - a path to the llvm sources for the llvm that will be used to build lldb LLVM_CONFIGURATION - the configuration that lldb is built for (Release, Release+Asserts, Debug, Debug+Asserts). I also changed the LLVM build to not check if "lldb/llvm" is a symlink and then assume it is a real llvm build directory versus the unzipped llvm.zip package, so now you can actually have a "lldb/llvm" directory in your lldb sources. llvm-svn: 129112
2011-04-08 06:46:35 +08:00
#include "lldb/Target/Platform.h"
Handle thumb IT instructions correctly all the time. 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
2014-12-10 07:31:02 +08:00
#include "lldb/Target/Process.h"
#include "lldb/Target/RegisterContext.h"
#include "lldb/Target/Thread.h"
Move some functions from source/lldb.cpp to Utility. 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
2015-03-19 05:31:45 +08:00
#include "lldb/Utility/NameMatches.h"
#include "lldb/Utility/SafeMachO.h"
Made lldb_private::ArchSpec more generic so that it can take a mach-o cpu type and sub-type, or an ELF e_machine value. Also added a generic CPU type to the arch spec class so we can have a single arch definition that the LLDB core code can use. Previously a lot of places in the code were using the mach-o definitions from a macosx header file. Switches over to using "llvm/Support/MachO.h" for the llvm::MachO::XXX for the CPU types and sub types for mach-o ArchSpecs. Added "llvm/Support/ELF.h" so we can use the "llvm::ELF::XXX" defines for the ELF ArchSpecs. Got rid of all CPU_TYPE_ and CPU_SUBTYPE_ defines that were previously being used in LLDB. llvm-svn: 105806
2010-06-11 11:25:34 +08:00
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
using namespace lldb;
using namespace lldb_private;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
static bool cores_match(const ArchSpec::Core core1, const ArchSpec::Core core2,
bool try_inverse, bool enforce_exact_match);
Add new ArchSpec methods, IsCompatibleMatch() and IsExactMatch(). The operator== method is a synonym for IsExactMatch(). The essential difference between these two is that IsCompatibleMatch() will say that armv7 and armv7s are compatible and return true. IsExactMatch() will say that armv7 and armv7s are not a match. An armv7s cpu can run either generic armv7 binaries or armv7s binaries (the latter being tuned for it). When we're picking the slice of a universal Mach-O file to load in an armv7s Target, we need to be able to first look for an exact cpu subtype match (armv7s == armv7s) and failing that, looking for a slice with a compatible architecture. Update ObjectContainerUniversalMachO::GetObjectFile to prefer an exact match of the cpu type, falling back to a compatible match if necessary. <rdar://problem/12593515> llvm-svn: 167365
2012-11-04 11:20:05 +08:00
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
namespace lldb_private {
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
struct CoreDefinition {
ByteOrder default_byte_order;
uint32_t addr_byte_size;
uint32_t min_opcode_byte_size;
uint32_t max_opcode_byte_size;
llvm::Triple::ArchType machine;
ArchSpec::Core core;
const char *const name;
};
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes. llvm-svn: 262441
2016-03-02 09:09:03 +08:00
} // namespace lldb_private
Made lldb_private::ArchSpec more generic so that it can take a mach-o cpu type and sub-type, or an ELF e_machine value. Also added a generic CPU type to the arch spec class so we can have a single arch definition that the LLDB core code can use. Previously a lot of places in the code were using the mach-o definitions from a macosx header file. Switches over to using "llvm/Support/MachO.h" for the llvm::MachO::XXX for the CPU types and sub types for mach-o ArchSpecs. Added "llvm/Support/ELF.h" so we can use the "llvm::ELF::XXX" defines for the ELF ArchSpecs. Got rid of all CPU_TYPE_ and CPU_SUBTYPE_ defines that were previously being used in LLDB. llvm-svn: 105806
2010-06-11 11:25:34 +08:00
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
// This core information can be looked using the ArchSpec::Core as the index
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
static const CoreDefinition g_core_definitions[] = {
{eByteOrderLittle, 4, 2, 4, llvm::Triple::arm, ArchSpec::eCore_arm_generic,
"arm"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::arm, ArchSpec::eCore_arm_armv4,
"armv4"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::arm, ArchSpec::eCore_arm_armv4t,
"armv4t"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::arm, ArchSpec::eCore_arm_armv5,
"armv5"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::arm, ArchSpec::eCore_arm_armv5e,
"armv5e"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::arm, ArchSpec::eCore_arm_armv5t,
"armv5t"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::arm, ArchSpec::eCore_arm_armv6,
"armv6"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::arm, ArchSpec::eCore_arm_armv6m,
"armv6m"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::arm, ArchSpec::eCore_arm_armv7,
"armv7"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::arm, ArchSpec::eCore_arm_armv7f,
"armv7f"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::arm, ArchSpec::eCore_arm_armv7s,
"armv7s"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::arm, ArchSpec::eCore_arm_armv7k,
"armv7k"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::arm, ArchSpec::eCore_arm_armv7m,
"armv7m"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::arm, ArchSpec::eCore_arm_armv7em,
"armv7em"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::arm, ArchSpec::eCore_arm_xscale,
"xscale"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::thumb, ArchSpec::eCore_thumb,
"thumb"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::thumb, ArchSpec::eCore_thumbv4t,
"thumbv4t"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::thumb, ArchSpec::eCore_thumbv5,
"thumbv5"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::thumb, ArchSpec::eCore_thumbv5e,
"thumbv5e"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::thumb, ArchSpec::eCore_thumbv6,
"thumbv6"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::thumb, ArchSpec::eCore_thumbv6m,
"thumbv6m"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::thumb, ArchSpec::eCore_thumbv7,
"thumbv7"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::thumb, ArchSpec::eCore_thumbv7f,
"thumbv7f"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::thumb, ArchSpec::eCore_thumbv7s,
"thumbv7s"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::thumb, ArchSpec::eCore_thumbv7k,
"thumbv7k"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::thumb, ArchSpec::eCore_thumbv7m,
"thumbv7m"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::thumb, ArchSpec::eCore_thumbv7em,
"thumbv7em"},
{eByteOrderLittle, 8, 4, 4, llvm::Triple::aarch64,
ArchSpec::eCore_arm_arm64, "arm64"},
{eByteOrderLittle, 8, 4, 4, llvm::Triple::aarch64,
ArchSpec::eCore_arm_armv8, "armv8"},
{eByteOrderLittle, 8, 4, 4, llvm::Triple::aarch64,
ArchSpec::eCore_arm_aarch64, "aarch64"},
POSIX RegisterContext for mips64 Based on the POSIX x86_64 register context. This is sufficient for opening a mips64 (big endian) core file. Subsequent changes will connect the disassembler, dynamic loader support, ABI, etc. Review: http://llvm-reviews.chandlerc.com/D1873 llvm-svn: 192335
2013-10-10 08:59:47 +08:00
[LLDB][MIPS] Add MIPS32 and MIPS64 core revisions 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
2015-04-23 14:36:20 +08:00
// mips32, mips32r2, mips32r3, mips32r5, mips32r6
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
{eByteOrderBig, 4, 2, 4, llvm::Triple::mips, ArchSpec::eCore_mips32,
"mips"},
{eByteOrderBig, 4, 2, 4, llvm::Triple::mips, ArchSpec::eCore_mips32r2,
"mipsr2"},
{eByteOrderBig, 4, 2, 4, llvm::Triple::mips, ArchSpec::eCore_mips32r3,
"mipsr3"},
{eByteOrderBig, 4, 2, 4, llvm::Triple::mips, ArchSpec::eCore_mips32r5,
"mipsr5"},
{eByteOrderBig, 4, 2, 4, llvm::Triple::mips, ArchSpec::eCore_mips32r6,
"mipsr6"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::mipsel, ArchSpec::eCore_mips32el,
"mipsel"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::mipsel,
ArchSpec::eCore_mips32r2el, "mipsr2el"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::mipsel,
ArchSpec::eCore_mips32r3el, "mipsr3el"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::mipsel,
ArchSpec::eCore_mips32r5el, "mipsr5el"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::mipsel,
ArchSpec::eCore_mips32r6el, "mipsr6el"},
Made lldb_private::ArchSpec more generic so that it can take a mach-o cpu type and sub-type, or an ELF e_machine value. Also added a generic CPU type to the arch spec class so we can have a single arch definition that the LLDB core code can use. Previously a lot of places in the code were using the mach-o definitions from a macosx header file. Switches over to using "llvm/Support/MachO.h" for the llvm::MachO::XXX for the CPU types and sub types for mach-o ArchSpecs. Added "llvm/Support/ELF.h" so we can use the "llvm::ELF::XXX" defines for the ELF ArchSpecs. Got rid of all CPU_TYPE_ and CPU_SUBTYPE_ defines that were previously being used in LLDB. llvm-svn: 105806
2010-06-11 11:25:34 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
// mips64, mips64r2, mips64r3, mips64r5, mips64r6
{eByteOrderBig, 8, 2, 4, llvm::Triple::mips64, ArchSpec::eCore_mips64,
"mips64"},
{eByteOrderBig, 8, 2, 4, llvm::Triple::mips64, ArchSpec::eCore_mips64r2,
"mips64r2"},
{eByteOrderBig, 8, 2, 4, llvm::Triple::mips64, ArchSpec::eCore_mips64r3,
"mips64r3"},
{eByteOrderBig, 8, 2, 4, llvm::Triple::mips64, ArchSpec::eCore_mips64r5,
"mips64r5"},
{eByteOrderBig, 8, 2, 4, llvm::Triple::mips64, ArchSpec::eCore_mips64r6,
"mips64r6"},
{eByteOrderLittle, 8, 2, 4, llvm::Triple::mips64el,
ArchSpec::eCore_mips64el, "mips64el"},
{eByteOrderLittle, 8, 2, 4, llvm::Triple::mips64el,
ArchSpec::eCore_mips64r2el, "mips64r2el"},
{eByteOrderLittle, 8, 2, 4, llvm::Triple::mips64el,
ArchSpec::eCore_mips64r3el, "mips64r3el"},
{eByteOrderLittle, 8, 2, 4, llvm::Triple::mips64el,
ArchSpec::eCore_mips64r5el, "mips64r5el"},
{eByteOrderLittle, 8, 2, 4, llvm::Triple::mips64el,
ArchSpec::eCore_mips64r6el, "mips64r6el"},
{eByteOrderBig, 4, 4, 4, llvm::Triple::ppc, ArchSpec::eCore_ppc_generic,
"powerpc"},
{eByteOrderBig, 4, 4, 4, llvm::Triple::ppc, ArchSpec::eCore_ppc_ppc601,
"ppc601"},
{eByteOrderBig, 4, 4, 4, llvm::Triple::ppc, ArchSpec::eCore_ppc_ppc602,
"ppc602"},
{eByteOrderBig, 4, 4, 4, llvm::Triple::ppc, ArchSpec::eCore_ppc_ppc603,
"ppc603"},
{eByteOrderBig, 4, 4, 4, llvm::Triple::ppc, ArchSpec::eCore_ppc_ppc603e,
"ppc603e"},
{eByteOrderBig, 4, 4, 4, llvm::Triple::ppc, ArchSpec::eCore_ppc_ppc603ev,
"ppc603ev"},
{eByteOrderBig, 4, 4, 4, llvm::Triple::ppc, ArchSpec::eCore_ppc_ppc604,
"ppc604"},
{eByteOrderBig, 4, 4, 4, llvm::Triple::ppc, ArchSpec::eCore_ppc_ppc604e,
"ppc604e"},
{eByteOrderBig, 4, 4, 4, llvm::Triple::ppc, ArchSpec::eCore_ppc_ppc620,
"ppc620"},
{eByteOrderBig, 4, 4, 4, llvm::Triple::ppc, ArchSpec::eCore_ppc_ppc750,
"ppc750"},
{eByteOrderBig, 4, 4, 4, llvm::Triple::ppc, ArchSpec::eCore_ppc_ppc7400,
"ppc7400"},
{eByteOrderBig, 4, 4, 4, llvm::Triple::ppc, ArchSpec::eCore_ppc_ppc7450,
"ppc7450"},
{eByteOrderBig, 4, 4, 4, llvm::Triple::ppc, ArchSpec::eCore_ppc_ppc970,
"ppc970"},
{eByteOrderBig, 8, 4, 4, llvm::Triple::ppc64, ArchSpec::eCore_ppc64_generic,
"powerpc64"},
{eByteOrderBig, 8, 4, 4, llvm::Triple::ppc64,
ArchSpec::eCore_ppc64_ppc970_64, "ppc970-64"},
{eByteOrderBig, 8, 2, 6, llvm::Triple::systemz,
ArchSpec::eCore_s390x_generic, "s390x"},
{eByteOrderLittle, 4, 4, 4, llvm::Triple::sparc,
ArchSpec::eCore_sparc_generic, "sparc"},
{eByteOrderLittle, 8, 4, 4, llvm::Triple::sparcv9,
ArchSpec::eCore_sparc9_generic, "sparcv9"},
{eByteOrderLittle, 4, 1, 15, llvm::Triple::x86, ArchSpec::eCore_x86_32_i386,
"i386"},
{eByteOrderLittle, 4, 1, 15, llvm::Triple::x86, ArchSpec::eCore_x86_32_i486,
"i486"},
{eByteOrderLittle, 4, 1, 15, llvm::Triple::x86,
ArchSpec::eCore_x86_32_i486sx, "i486sx"},
{eByteOrderLittle, 4, 1, 15, llvm::Triple::x86, ArchSpec::eCore_x86_32_i686,
"i686"},
{eByteOrderLittle, 8, 1, 15, llvm::Triple::x86_64,
ArchSpec::eCore_x86_64_x86_64, "x86_64"},
{eByteOrderLittle, 8, 1, 15, llvm::Triple::x86_64,
ArchSpec::eCore_x86_64_x86_64h, "x86_64h"},
{eByteOrderLittle, 4, 4, 4, llvm::Triple::hexagon,
ArchSpec::eCore_hexagon_generic, "hexagon"},
{eByteOrderLittle, 4, 4, 4, llvm::Triple::hexagon,
ArchSpec::eCore_hexagon_hexagonv4, "hexagonv4"},
{eByteOrderLittle, 4, 4, 4, llvm::Triple::hexagon,
ArchSpec::eCore_hexagon_hexagonv5, "hexagonv5"},
{eByteOrderLittle, 4, 4, 4, llvm::Triple::UnknownArch,
ArchSpec::eCore_uknownMach32, "unknown-mach-32"},
{eByteOrderLittle, 8, 4, 4, llvm::Triple::UnknownArch,
ArchSpec::eCore_uknownMach64, "unknown-mach-64"},
{eByteOrderBig, 4, 1, 1, llvm::Triple::kalimba, ArchSpec::eCore_kalimba3,
"kalimba3"},
{eByteOrderLittle, 4, 1, 1, llvm::Triple::kalimba, ArchSpec::eCore_kalimba4,
"kalimba4"},
{eByteOrderLittle, 4, 1, 1, llvm::Triple::kalimba, ArchSpec::eCore_kalimba5,
"kalimba5"}};
// Ensure that we have an entry in the g_core_definitions for each core. If you
// comment out an entry above,
Make sure we don't crash if someone (E.G.) comments out on entry from 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
2014-07-24 02:12:06 +08:00
// you will need to comment out the corresponding ArchSpec::Core enumeration.
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
static_assert(sizeof(g_core_definitions) / sizeof(CoreDefinition) ==
ArchSpec::kNumCores,
"make sure we have one core definition for each core");
struct ArchDefinitionEntry {
ArchSpec::Core core;
uint32_t cpu;
uint32_t sub;
uint32_t cpu_mask;
uint32_t sub_mask;
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
};
Made lldb_private::ArchSpec more generic so that it can take a mach-o cpu type and sub-type, or an ELF e_machine value. Also added a generic CPU type to the arch spec class so we can have a single arch definition that the LLDB core code can use. Previously a lot of places in the code were using the mach-o definitions from a macosx header file. Switches over to using "llvm/Support/MachO.h" for the llvm::MachO::XXX for the CPU types and sub types for mach-o ArchSpecs. Added "llvm/Support/ELF.h" so we can use the "llvm::ELF::XXX" defines for the ELF ArchSpecs. Got rid of all CPU_TYPE_ and CPU_SUBTYPE_ defines that were previously being used in LLDB. llvm-svn: 105806
2010-06-11 11:25:34 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
struct ArchDefinition {
ArchitectureType type;
size_t num_entries;
const ArchDefinitionEntry *entries;
const char *name;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
};
Convert AutoComplete related code to StringRef. Differential Revision: https://reviews.llvm.org/D26721 llvm-svn: 287188
2016-11-17 09:37:42 +08:00
size_t ArchSpec::AutoComplete(llvm::StringRef name, StringList &matches) {
if (!name.empty()) {
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
for (uint32_t i = 0; i < llvm::array_lengthof(g_core_definitions); ++i) {
if (NameMatches(g_core_definitions[i].name, eNameMatchStartsWith, name))
matches.AppendString(g_core_definitions[i].name);
Added auto completion for architecture names and for platforms. Modified the OptionGroupOptions to be able to specify only some of the options that should be appended by using the usage_mask in the group defintions and also provided a way to remap them to a new usage mask after the copy. This allows options to be re-used and also targetted for specific option groups. Modfied the CommandArgumentType to have a new eArgTypePlatform enumeration. Taught the option parser to be able to automatically use the appropriate auto completion for a given options if nothing is explicitly specified in the option definition. So you don't have to specify it in the option definition tables. Renamed the default host platform name to "host", and the default platform hostname to be "localhost". Modified the "file" and "platform select" commands to make sure all options and args are good prior to creating a new platform. Also defer the computation of the architecture in the file command until all options are parsed and the platform has either not been specified or reset to a new value to avoid computing the arch more than once. Switch the PluginManager code over to using llvm::StringRef for string comparisons and got rid of all the AccessorXXX functions in lieu of the newer mutex + collection singleton accessors. llvm-svn: 129483
2011-04-14 06:47:15 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
} else {
for (uint32_t i = 0; i < llvm::array_lengthof(g_core_definitions); ++i)
matches.AppendString(g_core_definitions[i].name);
}
return matches.GetSize();
Added auto completion for architecture names and for platforms. Modified the OptionGroupOptions to be able to specify only some of the options that should be appended by using the usage_mask in the group defintions and also provided a way to remap them to a new usage mask after the copy. This allows options to be re-used and also targetted for specific option groups. Modfied the CommandArgumentType to have a new eArgTypePlatform enumeration. Taught the option parser to be able to automatically use the appropriate auto completion for a given options if nothing is explicitly specified in the option definition. So you don't have to specify it in the option definition tables. Renamed the default host platform name to "host", and the default platform hostname to be "localhost". Modified the "file" and "platform select" commands to make sure all options and args are good prior to creating a new platform. Also defer the computation of the architecture in the file command until all options are parsed and the platform has either not been specified or reset to a new value to avoid computing the arch more than once. Switch the PluginManager code over to using llvm::StringRef for string comparisons and got rid of all the AccessorXXX functions in lieu of the newer mutex + collection singleton accessors. llvm-svn: 129483
2011-04-14 06:47:15 +08:00
}
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
#define CPU_ANY (UINT32_MAX)
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
//===----------------------------------------------------------------------===//
// A table that gets searched linearly for matches. This table is used to
// convert cpu type and subtypes to architecture names, and to convert
// architecture names to cpu types and subtypes. The ordering is important and
// allows the precedence to be set when the table is built.
A patch that allows for mach-o architectures to be specified as "<number>-<number>" where the first number is the cpu type and the second is the cpu subtype. Also added code to allow use of mach-o architectures that aren't in our tables so that symbolication and static file introspection (crashlogs) can work with them. llvm-svn: 164258
2012-09-20 06:25:17 +08:00
#define SUBTYPE_MASK 0x00FFFFFFu
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes. llvm-svn: 262441
2016-03-02 09:09:03 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
static const ArchDefinitionEntry g_macho_arch_entries[] = {
{ArchSpec::eCore_arm_generic, llvm::MachO::CPU_TYPE_ARM, CPU_ANY,
UINT32_MAX, UINT32_MAX},
{ArchSpec::eCore_arm_generic, llvm::MachO::CPU_TYPE_ARM, 0, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_arm_armv4, llvm::MachO::CPU_TYPE_ARM, 5, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_arm_armv4t, llvm::MachO::CPU_TYPE_ARM, 5, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_arm_armv6, llvm::MachO::CPU_TYPE_ARM, 6, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_arm_armv6m, llvm::MachO::CPU_TYPE_ARM, 14, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_arm_armv5, llvm::MachO::CPU_TYPE_ARM, 7, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_arm_armv5e, llvm::MachO::CPU_TYPE_ARM, 7, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_arm_armv5t, llvm::MachO::CPU_TYPE_ARM, 7, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_arm_xscale, llvm::MachO::CPU_TYPE_ARM, 8, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_arm_armv7, llvm::MachO::CPU_TYPE_ARM, 9, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_arm_armv7f, llvm::MachO::CPU_TYPE_ARM, 10, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_arm_armv7s, llvm::MachO::CPU_TYPE_ARM, 11, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_arm_armv7k, llvm::MachO::CPU_TYPE_ARM, 12, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_arm_armv7m, llvm::MachO::CPU_TYPE_ARM, 15, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_arm_armv7em, llvm::MachO::CPU_TYPE_ARM, 16, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_arm_arm64, llvm::MachO::CPU_TYPE_ARM64, 1, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_arm_arm64, llvm::MachO::CPU_TYPE_ARM64, 0, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_arm_arm64, llvm::MachO::CPU_TYPE_ARM64, 13, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_arm_arm64, llvm::MachO::CPU_TYPE_ARM64, CPU_ANY,
UINT32_MAX, SUBTYPE_MASK},
{ArchSpec::eCore_thumb, llvm::MachO::CPU_TYPE_ARM, 0, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_thumbv4t, llvm::MachO::CPU_TYPE_ARM, 5, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_thumbv5, llvm::MachO::CPU_TYPE_ARM, 7, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_thumbv5e, llvm::MachO::CPU_TYPE_ARM, 7, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_thumbv6, llvm::MachO::CPU_TYPE_ARM, 6, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_thumbv6m, llvm::MachO::CPU_TYPE_ARM, 14, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_thumbv7, llvm::MachO::CPU_TYPE_ARM, 9, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_thumbv7f, llvm::MachO::CPU_TYPE_ARM, 10, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_thumbv7s, llvm::MachO::CPU_TYPE_ARM, 11, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_thumbv7k, llvm::MachO::CPU_TYPE_ARM, 12, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_thumbv7m, llvm::MachO::CPU_TYPE_ARM, 15, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_thumbv7em, llvm::MachO::CPU_TYPE_ARM, 16, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_ppc_generic, llvm::MachO::CPU_TYPE_POWERPC, CPU_ANY,
UINT32_MAX, UINT32_MAX},
{ArchSpec::eCore_ppc_generic, llvm::MachO::CPU_TYPE_POWERPC, 0, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_ppc_ppc601, llvm::MachO::CPU_TYPE_POWERPC, 1, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_ppc_ppc602, llvm::MachO::CPU_TYPE_POWERPC, 2, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_ppc_ppc603, llvm::MachO::CPU_TYPE_POWERPC, 3, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_ppc_ppc603e, llvm::MachO::CPU_TYPE_POWERPC, 4, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_ppc_ppc603ev, llvm::MachO::CPU_TYPE_POWERPC, 5, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_ppc_ppc604, llvm::MachO::CPU_TYPE_POWERPC, 6, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_ppc_ppc604e, llvm::MachO::CPU_TYPE_POWERPC, 7, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_ppc_ppc620, llvm::MachO::CPU_TYPE_POWERPC, 8, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_ppc_ppc750, llvm::MachO::CPU_TYPE_POWERPC, 9, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_ppc_ppc7400, llvm::MachO::CPU_TYPE_POWERPC, 10, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_ppc_ppc7450, llvm::MachO::CPU_TYPE_POWERPC, 11, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_ppc_ppc970, llvm::MachO::CPU_TYPE_POWERPC, 100, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_ppc64_generic, llvm::MachO::CPU_TYPE_POWERPC64, 0,
UINT32_MAX, SUBTYPE_MASK},
{ArchSpec::eCore_ppc64_ppc970_64, llvm::MachO::CPU_TYPE_POWERPC64, 100,
UINT32_MAX, SUBTYPE_MASK},
{ArchSpec::eCore_x86_32_i386, llvm::MachO::CPU_TYPE_I386, 3, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_x86_32_i486, llvm::MachO::CPU_TYPE_I386, 4, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_x86_32_i486sx, llvm::MachO::CPU_TYPE_I386, 0x84,
UINT32_MAX, SUBTYPE_MASK},
{ArchSpec::eCore_x86_32_i386, llvm::MachO::CPU_TYPE_I386, CPU_ANY,
UINT32_MAX, UINT32_MAX},
{ArchSpec::eCore_x86_64_x86_64, llvm::MachO::CPU_TYPE_X86_64, 3, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_x86_64_x86_64, llvm::MachO::CPU_TYPE_X86_64, 4, UINT32_MAX,
SUBTYPE_MASK},
{ArchSpec::eCore_x86_64_x86_64h, llvm::MachO::CPU_TYPE_X86_64, 8,
UINT32_MAX, SUBTYPE_MASK},
{ArchSpec::eCore_x86_64_x86_64, llvm::MachO::CPU_TYPE_X86_64, CPU_ANY,
UINT32_MAX, UINT32_MAX},
// Catch any unknown mach architectures so we can always use the object and
// symbol mach-o files
{ArchSpec::eCore_uknownMach32, 0, 0, 0xFF000000u, 0x00000000u},
{ArchSpec::eCore_uknownMach64, llvm::MachO::CPU_ARCH_ABI64, 0, 0xFF000000u,
0x00000000u}};
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes. llvm-svn: 262441
2016-03-02 09:09:03 +08:00
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
static const ArchDefinition g_macho_arch_def = {
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
eArchTypeMachO, llvm::array_lengthof(g_macho_arch_entries),
g_macho_arch_entries, "mach-o"};
Made lldb_private::ArchSpec more generic so that it can take a mach-o cpu type and sub-type, or an ELF e_machine value. Also added a generic CPU type to the arch spec class so we can have a single arch definition that the LLDB core code can use. Previously a lot of places in the code were using the mach-o definitions from a macosx header file. Switches over to using "llvm/Support/MachO.h" for the llvm::MachO::XXX for the CPU types and sub types for mach-o ArchSpecs. Added "llvm/Support/ELF.h" so we can use the "llvm::ELF::XXX" defines for the ELF ArchSpecs. Got rid of all CPU_TYPE_ and CPU_SUBTYPE_ defines that were previously being used in LLDB. llvm-svn: 105806
2010-06-11 11:25:34 +08:00
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
//===----------------------------------------------------------------------===//
// A table that gets searched linearly for matches. This table is used to
// convert cpu type and subtypes to architecture names, and to convert
// architecture names to cpu types and subtypes. The ordering is important and
// allows the precedence to be set when the table is built.
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
static const ArchDefinitionEntry g_elf_arch_entries[] = {
{ArchSpec::eCore_sparc_generic, llvm::ELF::EM_SPARC, LLDB_INVALID_CPUTYPE,
0xFFFFFFFFu, 0xFFFFFFFFu}, // Sparc
{ArchSpec::eCore_x86_32_i386, llvm::ELF::EM_386, LLDB_INVALID_CPUTYPE,
0xFFFFFFFFu, 0xFFFFFFFFu}, // Intel 80386
{ArchSpec::eCore_x86_32_i486, llvm::ELF::EM_IAMCU, LLDB_INVALID_CPUTYPE,
0xFFFFFFFFu, 0xFFFFFFFFu}, // Intel MCU // FIXME: is this correct?
{ArchSpec::eCore_ppc_generic, llvm::ELF::EM_PPC, LLDB_INVALID_CPUTYPE,
0xFFFFFFFFu, 0xFFFFFFFFu}, // PowerPC
{ArchSpec::eCore_ppc64_generic, llvm::ELF::EM_PPC64, LLDB_INVALID_CPUTYPE,
0xFFFFFFFFu, 0xFFFFFFFFu}, // PowerPC64
{ArchSpec::eCore_arm_generic, llvm::ELF::EM_ARM, LLDB_INVALID_CPUTYPE,
0xFFFFFFFFu, 0xFFFFFFFFu}, // ARM
{ArchSpec::eCore_arm_aarch64, llvm::ELF::EM_AARCH64, LLDB_INVALID_CPUTYPE,
0xFFFFFFFFu, 0xFFFFFFFFu}, // ARM64
{ArchSpec::eCore_s390x_generic, llvm::ELF::EM_S390, LLDB_INVALID_CPUTYPE,
0xFFFFFFFFu, 0xFFFFFFFFu}, // SystemZ
{ArchSpec::eCore_sparc9_generic, llvm::ELF::EM_SPARCV9,
LLDB_INVALID_CPUTYPE, 0xFFFFFFFFu, 0xFFFFFFFFu}, // SPARC V9
{ArchSpec::eCore_x86_64_x86_64, llvm::ELF::EM_X86_64, LLDB_INVALID_CPUTYPE,
0xFFFFFFFFu, 0xFFFFFFFFu}, // AMD64
{ArchSpec::eCore_mips32, llvm::ELF::EM_MIPS, ArchSpec::eMIPSSubType_mips32,
0xFFFFFFFFu, 0xFFFFFFFFu}, // mips32
{ArchSpec::eCore_mips32r2, llvm::ELF::EM_MIPS,
ArchSpec::eMIPSSubType_mips32r2, 0xFFFFFFFFu, 0xFFFFFFFFu}, // mips32r2
{ArchSpec::eCore_mips32r6, llvm::ELF::EM_MIPS,
ArchSpec::eMIPSSubType_mips32r6, 0xFFFFFFFFu, 0xFFFFFFFFu}, // mips32r6
{ArchSpec::eCore_mips32el, llvm::ELF::EM_MIPS,
ArchSpec::eMIPSSubType_mips32el, 0xFFFFFFFFu, 0xFFFFFFFFu}, // mips32el
{ArchSpec::eCore_mips32r2el, llvm::ELF::EM_MIPS,
ArchSpec::eMIPSSubType_mips32r2el, 0xFFFFFFFFu, 0xFFFFFFFFu}, // mips32r2el
{ArchSpec::eCore_mips32r6el, llvm::ELF::EM_MIPS,
ArchSpec::eMIPSSubType_mips32r6el, 0xFFFFFFFFu, 0xFFFFFFFFu}, // mips32r6el
{ArchSpec::eCore_mips64, llvm::ELF::EM_MIPS, ArchSpec::eMIPSSubType_mips64,
0xFFFFFFFFu, 0xFFFFFFFFu}, // mips64
{ArchSpec::eCore_mips64r2, llvm::ELF::EM_MIPS,
ArchSpec::eMIPSSubType_mips64r2, 0xFFFFFFFFu, 0xFFFFFFFFu}, // mips64r2
{ArchSpec::eCore_mips64r6, llvm::ELF::EM_MIPS,
ArchSpec::eMIPSSubType_mips64r6, 0xFFFFFFFFu, 0xFFFFFFFFu}, // mips64r6
{ArchSpec::eCore_mips64el, llvm::ELF::EM_MIPS,
ArchSpec::eMIPSSubType_mips64el, 0xFFFFFFFFu, 0xFFFFFFFFu}, // mips64el
{ArchSpec::eCore_mips64r2el, llvm::ELF::EM_MIPS,
ArchSpec::eMIPSSubType_mips64r2el, 0xFFFFFFFFu, 0xFFFFFFFFu}, // mips64r2el
{ArchSpec::eCore_mips64r6el, llvm::ELF::EM_MIPS,
ArchSpec::eMIPSSubType_mips64r6el, 0xFFFFFFFFu, 0xFFFFFFFFu}, // mips64r6el
{ArchSpec::eCore_hexagon_generic, llvm::ELF::EM_HEXAGON,
LLDB_INVALID_CPUTYPE, 0xFFFFFFFFu, 0xFFFFFFFFu}, // HEXAGON
{ArchSpec::eCore_kalimba3, llvm::ELF::EM_CSR_KALIMBA,
llvm::Triple::KalimbaSubArch_v3, 0xFFFFFFFFu, 0xFFFFFFFFu}, // KALIMBA
{ArchSpec::eCore_kalimba4, llvm::ELF::EM_CSR_KALIMBA,
llvm::Triple::KalimbaSubArch_v4, 0xFFFFFFFFu, 0xFFFFFFFFu}, // KALIMBA
{ArchSpec::eCore_kalimba5, llvm::ELF::EM_CSR_KALIMBA,
llvm::Triple::KalimbaSubArch_v5, 0xFFFFFFFFu, 0xFFFFFFFFu} // KALIMBA
Made lldb_private::ArchSpec more generic so that it can take a mach-o cpu type and sub-type, or an ELF e_machine value. Also added a generic CPU type to the arch spec class so we can have a single arch definition that the LLDB core code can use. Previously a lot of places in the code were using the mach-o definitions from a macosx header file. Switches over to using "llvm/Support/MachO.h" for the llvm::MachO::XXX for the CPU types and sub types for mach-o ArchSpecs. Added "llvm/Support/ELF.h" so we can use the "llvm::ELF::XXX" defines for the ELF ArchSpecs. Got rid of all CPU_TYPE_ and CPU_SUBTYPE_ defines that were previously being used in LLDB. llvm-svn: 105806
2010-06-11 11:25:34 +08:00
};
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
static const ArchDefinition g_elf_arch_def = {
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
eArchTypeELF, llvm::array_lengthof(g_elf_arch_entries), g_elf_arch_entries,
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
"elf",
};
Made lldb_private::ArchSpec more generic so that it can take a mach-o cpu type and sub-type, or an ELF e_machine value. Also added a generic CPU type to the arch spec class so we can have a single arch definition that the LLDB core code can use. Previously a lot of places in the code were using the mach-o definitions from a macosx header file. Switches over to using "llvm/Support/MachO.h" for the llvm::MachO::XXX for the CPU types and sub types for mach-o ArchSpecs. Added "llvm/Support/ELF.h" so we can use the "llvm::ELF::XXX" defines for the ELF ArchSpecs. Got rid of all CPU_TYPE_ and CPU_SUBTYPE_ defines that were previously being used in LLDB. llvm-svn: 105806
2010-06-11 11:25:34 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
static const ArchDefinitionEntry g_coff_arch_entries[] = {
{ArchSpec::eCore_x86_32_i386, llvm::COFF::IMAGE_FILE_MACHINE_I386,
LLDB_INVALID_CPUTYPE, 0xFFFFFFFFu, 0xFFFFFFFFu}, // Intel 80x86
{ArchSpec::eCore_ppc_generic, llvm::COFF::IMAGE_FILE_MACHINE_POWERPC,
LLDB_INVALID_CPUTYPE, 0xFFFFFFFFu, 0xFFFFFFFFu}, // PowerPC
{ArchSpec::eCore_ppc_generic, llvm::COFF::IMAGE_FILE_MACHINE_POWERPCFP,
LLDB_INVALID_CPUTYPE, 0xFFFFFFFFu, 0xFFFFFFFFu}, // PowerPC (with FPU)
{ArchSpec::eCore_arm_generic, llvm::COFF::IMAGE_FILE_MACHINE_ARM,
LLDB_INVALID_CPUTYPE, 0xFFFFFFFFu, 0xFFFFFFFFu}, // ARM
{ArchSpec::eCore_arm_armv7, llvm::COFF::IMAGE_FILE_MACHINE_ARMNT,
LLDB_INVALID_CPUTYPE, 0xFFFFFFFFu, 0xFFFFFFFFu}, // ARMv7
{ArchSpec::eCore_thumb, llvm::COFF::IMAGE_FILE_MACHINE_THUMB,
LLDB_INVALID_CPUTYPE, 0xFFFFFFFFu, 0xFFFFFFFFu}, // ARMv7
{ArchSpec::eCore_x86_64_x86_64, llvm::COFF::IMAGE_FILE_MACHINE_AMD64,
LLDB_INVALID_CPUTYPE, 0xFFFFFFFFu, 0xFFFFFFFFu} // AMD64
Plugins/ObjectFile/PECOFF: Use enums from LLVM, and don't use Mach-O definitions. Since I renamed most of the LLVM Mach-O enums in r189314, I had to go fix LLDB to use the new names. While I was here, I decided that a COFF plugin really shouldn't be using Mach-O enums. llvm-svn: 189316
2013-08-27 13:04:33 +08:00
};
static const ArchDefinition g_coff_arch_def = {
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
eArchTypeCOFF, llvm::array_lengthof(g_coff_arch_entries),
g_coff_arch_entries, "pe-coff",
Plugins/ObjectFile/PECOFF: Use enums from LLVM, and don't use Mach-O definitions. Since I renamed most of the LLVM Mach-O enums in r189314, I had to go fix LLDB to use the new names. While I was here, I decided that a COFF plugin really shouldn't be using Mach-O enums. llvm-svn: 189316
2013-08-27 13:04:33 +08:00
};
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
//===----------------------------------------------------------------------===//
// Table of all ArchDefinitions
static const ArchDefinition *g_arch_definitions[] = {
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
&g_macho_arch_def, &g_elf_arch_def, &g_coff_arch_def};
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
static const size_t k_num_arch_definitions =
llvm::array_lengthof(g_arch_definitions);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
//===----------------------------------------------------------------------===//
// Static helper functions.
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
// Get the architecture definition for a given object type.
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
static const ArchDefinition *FindArchDefinition(ArchitectureType arch_type) {
for (unsigned int i = 0; i < k_num_arch_definitions; ++i) {
const ArchDefinition *def = g_arch_definitions[i];
if (def->type == arch_type)
return def;
}
return nullptr;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
// Get an architecture definition by name.
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
static const CoreDefinition *FindCoreDefinition(llvm::StringRef name) {
for (unsigned int i = 0; i < llvm::array_lengthof(g_core_definitions); ++i) {
if (name.equals_lower(g_core_definitions[i].name))
return &g_core_definitions[i];
}
return nullptr;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
static inline const CoreDefinition *FindCoreDefinition(ArchSpec::Core core) {
if (core >= 0 && core < llvm::array_lengthof(g_core_definitions))
return &g_core_definitions[core];
return nullptr;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
// Get a definition entry by cpu type and subtype.
static const ArchDefinitionEntry *
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
FindArchDefinitionEntry(const ArchDefinition *def, uint32_t cpu, uint32_t sub) {
if (def == nullptr)
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes. llvm-svn: 262441
2016-03-02 09:09:03 +08:00
return nullptr;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
const ArchDefinitionEntry *entries = def->entries;
for (size_t i = 0; i < def->num_entries; ++i) {
if (entries[i].cpu == (cpu & entries[i].cpu_mask))
if (entries[i].sub == (sub & entries[i].sub_mask))
return &entries[i];
}
return nullptr;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
static const ArchDefinitionEntry *
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
FindArchDefinitionEntry(const ArchDefinition *def, ArchSpec::Core core) {
if (def == nullptr)
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes. llvm-svn: 262441
2016-03-02 09:09:03 +08:00
return nullptr;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
const ArchDefinitionEntry *entries = def->entries;
for (size_t i = 0; i < def->num_entries; ++i) {
if (entries[i].core == core)
return &entries[i];
}
return nullptr;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
//===----------------------------------------------------------------------===//
// Constructors and destructors.
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Allow ArchSpec to take a StringRef. llvm-svn: 281662
2016-09-16 05:32:57 +08:00
ArchSpec::ArchSpec() {}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Allow ArchSpec to take a StringRef. llvm-svn: 281662
2016-09-16 05:32:57 +08:00
ArchSpec::ArchSpec(const char *triple_cstr, Platform *platform) {
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
if (triple_cstr)
SetTriple(triple_cstr, platform);
Made lldb_private::ArchSpec more generic so that it can take a mach-o cpu type and sub-type, or an ELF e_machine value. Also added a generic CPU type to the arch spec class so we can have a single arch definition that the LLDB core code can use. Previously a lot of places in the code were using the mach-o definitions from a macosx header file. Switches over to using "llvm/Support/MachO.h" for the llvm::MachO::XXX for the CPU types and sub types for mach-o ArchSpecs. Added "llvm/Support/ELF.h" so we can use the "llvm::ELF::XXX" defines for the ELF ArchSpecs. Got rid of all CPU_TYPE_ and CPU_SUBTYPE_ defines that were previously being used in LLDB. llvm-svn: 105806
2010-06-11 11:25:34 +08:00
}
Allow ArchSpec to take a StringRef. llvm-svn: 281662
2016-09-16 05:32:57 +08:00
ArchSpec::ArchSpec(llvm::StringRef triple_str, Platform *platform) {
SetTriple(triple_str, platform);
}
ArchSpec::ArchSpec(const char *triple_cstr) {
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
if (triple_cstr)
SetTriple(triple_cstr);
<rdar://problem/11358639> Switch over to the "*-apple-macosx" for desktop and "*-apple-ios" for iOS triples. Also make the selection process for auto selecting platforms based off of an arch much better. llvm-svn: 156354
2012-05-08 09:45:38 +08:00
}
Allow ArchSpec to take a StringRef. llvm-svn: 281662
2016-09-16 05:32:57 +08:00
ArchSpec::ArchSpec(llvm::StringRef triple_str) { SetTriple(triple_str); }
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Allow ArchSpec to take a StringRef. llvm-svn: 281662
2016-09-16 05:32:57 +08:00
ArchSpec::ArchSpec(const llvm::Triple &triple) { SetTriple(triple); }
ArchSpec::ArchSpec(ArchitectureType arch_type, uint32_t cpu, uint32_t subtype) {
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
SetArchitecture(arch_type, cpu, subtype);
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes. llvm-svn: 262441
2016-03-02 09:09:03 +08:00
ArchSpec::~ArchSpec() = default;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
//===----------------------------------------------------------------------===//
// Assignment and initialization.
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
const ArchSpec &ArchSpec::operator=(const ArchSpec &rhs) {
if (this != &rhs) {
m_triple = rhs.m_triple;
m_core = rhs.m_core;
m_byte_order = rhs.m_byte_order;
m_distribution_id = rhs.m_distribution_id;
m_flags = rhs.m_flags;
}
return *this;
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
void ArchSpec::Clear() {
m_triple = llvm::Triple();
m_core = kCore_invalid;
m_byte_order = eByteOrderInvalid;
m_distribution_id.Clear();
m_flags = 0;
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
//===----------------------------------------------------------------------===//
// Predicates.
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
const char *ArchSpec::GetArchitectureName() const {
const CoreDefinition *core_def = FindCoreDefinition(m_core);
if (core_def)
return core_def->name;
return "unknown";
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
bool ArchSpec::IsMIPS() const {
const llvm::Triple::ArchType machine = GetMachine();
if (machine == llvm::Triple::mips || machine == llvm::Triple::mipsel ||
machine == llvm::Triple::mips64 || machine == llvm::Triple::mips64el)
return true;
return false;
[LLDB][MIPS] Setting appropriate ArchSpec::m_flags based on ABI 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
2016-05-11 21:08:29 +08:00
}
[LLDB][MIPS] Fix qProcessInfo to return correct pointer size based on ELF ABI Reviewers: clayborg, labath Subscribers: jaydeep, bhushan, slthakur, lldb-commits Differential Revision: https://reviews.llvm.org/D25021 llvm-svn: 284001
2016-10-12 18:21:09 +08:00
std::string ArchSpec::GetTargetABI() const {
std::string abi;
if (IsMIPS()) {
switch (GetFlags() & ArchSpec::eMIPSABI_mask) {
case ArchSpec::eMIPSABI_N64:
abi = "n64";
return abi;
case ArchSpec::eMIPSABI_N32:
abi = "n32";
return abi;
case ArchSpec::eMIPSABI_O32:
abi = "o32";
return abi;
default:
return abi;
}
}
return abi;
}
void ArchSpec::SetFlags(std::string elf_abi) {
uint32_t flag = GetFlags();
if (IsMIPS()) {
if (elf_abi == "n64")
flag |= ArchSpec::eMIPSABI_N64;
else if (elf_abi == "n32")
flag |= ArchSpec::eMIPSABI_N32;
else if (elf_abi == "o32")
flag |= ArchSpec::eMIPSABI_O32;
}
SetFlags(flag);
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
std::string ArchSpec::GetClangTargetCPU() {
std::string cpu;
const llvm::Triple::ArchType machine = GetMachine();
if (machine == llvm::Triple::mips || machine == llvm::Triple::mipsel ||
machine == llvm::Triple::mips64 || machine == llvm::Triple::mips64el) {
switch (m_core) {
case ArchSpec::eCore_mips32:
case ArchSpec::eCore_mips32el:
cpu = "mips32";
break;
case ArchSpec::eCore_mips32r2:
case ArchSpec::eCore_mips32r2el:
cpu = "mips32r2";
break;
case ArchSpec::eCore_mips32r3:
case ArchSpec::eCore_mips32r3el:
cpu = "mips32r3";
break;
case ArchSpec::eCore_mips32r5:
case ArchSpec::eCore_mips32r5el:
cpu = "mips32r5";
break;
case ArchSpec::eCore_mips32r6:
case ArchSpec::eCore_mips32r6el:
cpu = "mips32r6";
break;
case ArchSpec::eCore_mips64:
case ArchSpec::eCore_mips64el:
cpu = "mips64";
break;
case ArchSpec::eCore_mips64r2:
case ArchSpec::eCore_mips64r2el:
cpu = "mips64r2";
break;
case ArchSpec::eCore_mips64r3:
case ArchSpec::eCore_mips64r3el:
cpu = "mips64r3";
break;
case ArchSpec::eCore_mips64r5:
case ArchSpec::eCore_mips64r5el:
cpu = "mips64r5";
break;
case ArchSpec::eCore_mips64r6:
case ArchSpec::eCore_mips64r6el:
cpu = "mips64r6";
break;
default:
break;
[LLDB][MIPS] Provide CPU string to compiler for appropriate code generation 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
2016-02-18 19:53:28 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
return cpu;
[LLDB][MIPS] Provide CPU string to compiler for appropriate code generation 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
2016-02-18 19:53:28 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
uint32_t ArchSpec::GetMachOCPUType() const {
const CoreDefinition *core_def = FindCoreDefinition(m_core);
if (core_def) {
const ArchDefinitionEntry *arch_def =
FindArchDefinitionEntry(&g_macho_arch_def, core_def->core);
if (arch_def) {
return arch_def->cpu;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
return LLDB_INVALID_CPUTYPE;
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
uint32_t ArchSpec::GetMachOCPUSubType() const {
const CoreDefinition *core_def = FindCoreDefinition(m_core);
if (core_def) {
const ArchDefinitionEntry *arch_def =
FindArchDefinitionEntry(&g_macho_arch_def, core_def->core);
if (arch_def) {
return arch_def->sub;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
return LLDB_INVALID_CPUTYPE;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
uint32_t ArchSpec::GetDataByteSize() const {
switch (m_core) {
case eCore_kalimba3:
return 4;
case eCore_kalimba4:
Add an interface on ArchSpec to provide lldb client code with a mechanism to query if the current target architecture has non 8-bit bytes. llvm-svn: 216867
2014-09-01 17:06:03 +08:00
return 1;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
case eCore_kalimba5:
return 4;
default:
return 1;
}
return 1;
Add an interface on ArchSpec to provide lldb client code with a mechanism to query if the current target architecture has non 8-bit bytes. llvm-svn: 216867
2014-09-01 17:06:03 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
uint32_t ArchSpec::GetCodeByteSize() const {
switch (m_core) {
case eCore_kalimba3:
return 4;
case eCore_kalimba4:
return 1;
case eCore_kalimba5:
return 1;
default:
Add an interface on ArchSpec to provide lldb client code with a mechanism to query if the current target architecture has non 8-bit bytes. llvm-svn: 216867
2014-09-01 17:06:03 +08:00
return 1;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
return 1;
Add an interface on ArchSpec to provide lldb client code with a mechanism to query if the current target architecture has non 8-bit bytes. llvm-svn: 216867
2014-09-01 17:06:03 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
llvm::Triple::ArchType ArchSpec::GetMachine() const {
const CoreDefinition *core_def = FindCoreDefinition(m_core);
if (core_def)
return core_def->machine;
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
return llvm::Triple::UnknownArch;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
const ConstString &ArchSpec::GetDistributionId() const {
return m_distribution_id;
Added distribution info to ArchSpec and qHostInfo message. ArchSpec now contains an optional distribution_id, with getters and setters. Host::GetArchitecture () sets it on non-Apple platforms using Host::GetDistributionId (). The distribution_id is ignored during ArchSpec comparisons. The gdb remote qHostInfo message transmits it, if set, via the distribution_id={id-value} key/value pair. Updated gdb remote docs to reflect this change. As before, GetDistributionId () returns nothing on non-Linux platforms at this time. On Linux, it is returned only if the lsb_platform command is installed (in /bin or /usr/bin), and only if the distributor id key is returned by 'lsb_platform -i'. This id is lowercased, and whitespace is replaced with underscores. llvm-svn: 199539
2014-01-18 11:02:39 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
void ArchSpec::SetDistributionId(const char *distribution_id) {
m_distribution_id.SetCString(distribution_id);
Added distribution info to ArchSpec and qHostInfo message. ArchSpec now contains an optional distribution_id, with getters and setters. Host::GetArchitecture () sets it on non-Apple platforms using Host::GetDistributionId (). The distribution_id is ignored during ArchSpec comparisons. The gdb remote qHostInfo message transmits it, if set, via the distribution_id={id-value} key/value pair. Updated gdb remote docs to reflect this change. As before, GetDistributionId () returns nothing on non-Linux platforms at this time. On Linux, it is returned only if the lsb_platform command is installed (in /bin or /usr/bin), and only if the distributor id key is returned by 'lsb_platform -i'. This id is lowercased, and whitespace is replaced with underscores. llvm-svn: 199539
2014-01-18 11:02:39 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
uint32_t ArchSpec::GetAddressByteSize() const {
const CoreDefinition *core_def = FindCoreDefinition(m_core);
if (core_def) {
if (core_def->machine == llvm::Triple::mips64 ||
core_def->machine == llvm::Triple::mips64el) {
// For N32/O32 applications Address size is 4 bytes.
if (m_flags & (eMIPSABI_N32 | eMIPSABI_O32))
return 4;
[LLDB][MIPS] Added support for the debugging of N32/O32 applications on 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
2015-09-09 18:32:20 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
return core_def->addr_byte_size;
}
return 0;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
ByteOrder ArchSpec::GetDefaultEndian() const {
const CoreDefinition *core_def = FindCoreDefinition(m_core);
if (core_def)
return core_def->default_byte_order;
return eByteOrderInvalid;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
bool ArchSpec::CharIsSignedByDefault() const {
switch (m_triple.getArch()) {
default:
return true;
case llvm::Triple::aarch64:
case llvm::Triple::aarch64_be:
case llvm::Triple::arm:
case llvm::Triple::armeb:
case llvm::Triple::thumb:
case llvm::Triple::thumbeb:
return m_triple.isOSDarwin() || m_triple.isOSWindows();
case llvm::Triple::ppc:
case llvm::Triple::ppc64:
return m_triple.isOSDarwin();
case llvm::Triple::ppc64le:
case llvm::Triple::systemz:
case llvm::Triple::xcore:
return false;
}
Fix type detection for 'char' variables 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
2015-03-31 18:21:50 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
lldb::ByteOrder ArchSpec::GetByteOrder() const {
if (m_byte_order == eByteOrderInvalid)
return GetDefaultEndian();
return m_byte_order;
Made lldb_private::ArchSpec contain much more than just an architecture. It now, in addition to cpu type/subtype and architecture flavor, contains: - byte order (big endian, little endian) - address size in bytes - llvm::Triple for true target triple support and for more powerful plug-in selection. llvm-svn: 125602
2011-02-16 05:59:32 +08:00
}
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
//===----------------------------------------------------------------------===//
// Mutators.
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
bool ArchSpec::SetTriple(const llvm::Triple &triple) {
m_triple = triple;
llvm::StringRef arch_name(m_triple.getArchName());
const CoreDefinition *core_def = FindCoreDefinition(arch_name);
if (core_def) {
m_core = core_def->core;
// Set the byte order to the default byte order for an architecture.
// This can be modified if needed for cases when cores handle both
// big and little endian
m_byte_order = core_def->default_byte_order;
} else {
Clear();
}
return IsValid();
Made lldb_private::ArchSpec contain much more than just an architecture. It now, in addition to cpu type/subtype and architecture flavor, contains: - byte order (big endian, little endian) - address size in bytes - llvm::Triple for true target triple support and for more powerful plug-in selection. llvm-svn: 125602
2011-02-16 05:59:32 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
[LLDB][MIPS] Fix qProcessInfo to return correct pointer size based on ELF ABI Reviewers: clayborg, labath Subscribers: jaydeep, bhushan, slthakur, lldb-commits Differential Revision: https://reviews.llvm.org/D25021 llvm-svn: 284001
2016-10-12 18:21:09 +08:00
bool lldb_private::ParseMachCPUDashSubtypeTriple(llvm::StringRef triple_str,
ArchSpec &arch) {
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
// Accept "12-10" or "12.10" as cpu type/subtype
Convert ArchSpec::ParseMachOCPUDashSubtypeTriple to use StringRef. This makes the code easier to grok, and since this is a very low level function it also is very helpful to have this take a StringRef since it means anyone higher up the chain who has a StringRef would have to first convert it to a null-terminated string. This way it can work equally well with StringRefs or const char*'s, which will enable the conversion of higher up functions to StringRef. Tested on Windows, Linux, and OSX and saw no regressions. llvm-svn: 281642
2016-09-16 02:41:48 +08:00
if (triple_str.empty())
return false;
size_t pos = triple_str.find_first_of("-.");
if (pos == llvm::StringRef::npos)
return false;
llvm::StringRef cpu_str = triple_str.substr(0, pos);
llvm::StringRef remainder = triple_str.substr(pos + 1);
if (cpu_str.empty() || remainder.empty())
return false;
llvm::StringRef sub_str;
llvm::StringRef vendor;
llvm::StringRef os;
std::tie(sub_str, remainder) = remainder.split('-');
std::tie(vendor, os) = remainder.split('-');
uint32_t cpu = 0;
uint32_t sub = 0;
if (cpu_str.getAsInteger(10, cpu) || sub_str.getAsInteger(10, sub))
return false;
if (!arch.SetArchitecture(eArchTypeMachO, cpu, sub))
return false;
if (!vendor.empty() && !os.empty()) {
arch.GetTriple().setVendorName(vendor);
arch.GetTriple().setOSName(os);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
Convert ArchSpec::ParseMachOCPUDashSubtypeTriple to use StringRef. This makes the code easier to grok, and since this is a very low level function it also is very helpful to have this take a StringRef since it means anyone higher up the chain who has a StringRef would have to first convert it to a null-terminated string. This way it can work equally well with StringRefs or const char*'s, which will enable the conversion of higher up functions to StringRef. Tested on Windows, Linux, and OSX and saw no regressions. llvm-svn: 281642
2016-09-16 02:41:48 +08:00
return true;
A patch that allows for mach-o architectures to be specified as "<number>-<number>" where the first number is the cpu type and the second is the cpu subtype. Also added code to allow use of mach-o architectures that aren't in our tables so that symbolication and static file introspection (crashlogs) can work with them. llvm-svn: 164258
2012-09-20 06:25:17 +08:00
}
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes. llvm-svn: 262441
2016-03-02 09:09:03 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
bool ArchSpec::SetTriple(const char *triple_cstr) {
Allow ArchSpec to take a StringRef. llvm-svn: 281662
2016-09-16 05:32:57 +08:00
llvm::StringRef str(triple_cstr ? triple_cstr : "");
return SetTriple(str);
}
bool ArchSpec::SetTriple(const char *triple_cstr, Platform *platform) {
llvm::StringRef str(triple_cstr ? triple_cstr : "");
return SetTriple(str, platform);
}
bool ArchSpec::SetTriple(llvm::StringRef triple) {
if (triple.empty()) {
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
Clear();
Allow ArchSpec to take a StringRef. llvm-svn: 281662
2016-09-16 05:32:57 +08:00
return false;
}
if (ParseMachCPUDashSubtypeTriple(triple, *this))
return true;
if (triple.startswith(LLDB_ARCH_DEFAULT)) {
// Special case for the current host default architectures...
if (triple.equals(LLDB_ARCH_DEFAULT_32BIT))
*this = HostInfo::GetArchitecture(HostInfo::eArchKind32);
else if (triple.equals(LLDB_ARCH_DEFAULT_64BIT))
*this = HostInfo::GetArchitecture(HostInfo::eArchKind64);
else if (triple.equals(LLDB_ARCH_DEFAULT))
*this = HostInfo::GetArchitecture(HostInfo::eArchKindDefault);
} else {
SetTriple(llvm::Triple(llvm::Triple::normalize(triple)));
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
return IsValid();
<rdar://problem/11358639> Switch over to the "*-apple-macosx" for desktop and "*-apple-ios" for iOS triples. Also make the selection process for auto selecting platforms based off of an arch much better. llvm-svn: 156354
2012-05-08 09:45:38 +08:00
}
Allow ArchSpec to take a StringRef. llvm-svn: 281662
2016-09-16 05:32:57 +08:00
bool ArchSpec::SetTriple(llvm::StringRef triple, Platform *platform) {
if (triple.empty()) {
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
Clear();
Allow ArchSpec to take a StringRef. llvm-svn: 281662
2016-09-16 05:32:57 +08:00
return false;
}
if (ParseMachCPUDashSubtypeTriple(triple, *this))
return true;
if (triple.startswith(LLDB_ARCH_DEFAULT)) {
// Special case for the current host default architectures...
if (triple.equals(LLDB_ARCH_DEFAULT_32BIT))
*this = HostInfo::GetArchitecture(HostInfo::eArchKind32);
else if (triple.equals(LLDB_ARCH_DEFAULT_64BIT))
*this = HostInfo::GetArchitecture(HostInfo::eArchKind64);
else if (triple.equals(LLDB_ARCH_DEFAULT))
*this = HostInfo::GetArchitecture(HostInfo::eArchKindDefault);
return IsValid();
}
ArchSpec raw_arch(triple);
llvm::Triple normalized_triple(llvm::Triple::normalize(triple));
const bool os_specified = !normalized_triple.getOSName().empty();
const bool vendor_specified = !normalized_triple.getVendorName().empty();
const bool env_specified = !normalized_triple.getEnvironmentName().empty();
if (os_specified || vendor_specified || env_specified) {
SetTriple(normalized_triple);
return IsValid();
}
// We got an arch only. If there is no platform, fallback to the host system
// for defaults.
if (!platform) {
llvm::Triple host_triple(llvm::sys::getDefaultTargetTriple());
if (!vendor_specified)
normalized_triple.setVendor(host_triple.getVendor());
if (!vendor_specified)
normalized_triple.setOS(host_triple.getOS());
if (!env_specified && host_triple.getEnvironmentName().size())
normalized_triple.setEnvironment(host_triple.getEnvironment());
SetTriple(normalized_triple);
return IsValid();
}
// If we were given a platform, use the platform's system architecture. If
// this is not available (might not be connected) use the first supported
// architecture.
ArchSpec compatible_arch;
if (!platform->IsCompatibleArchitecture(raw_arch, false, &compatible_arch)) {
*this = raw_arch;
return IsValid();
}
if (compatible_arch.IsValid()) {
const llvm::Triple &compatible_triple = compatible_arch.GetTriple();
if (!vendor_specified)
normalized_triple.setVendor(compatible_triple.getVendor());
if (!os_specified)
normalized_triple.setOS(compatible_triple.getOS());
if (!env_specified && compatible_triple.hasEnvironment())
normalized_triple.setEnvironment(compatible_triple.getEnvironment());
}
SetTriple(normalized_triple);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
return IsValid();
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
void ArchSpec::MergeFrom(const ArchSpec &other) {
if (TripleVendorIsUnspecifiedUnknown() &&
!other.TripleVendorIsUnspecifiedUnknown())
GetTriple().setVendor(other.GetTriple().getVendor());
if (TripleOSIsUnspecifiedUnknown() && !other.TripleOSIsUnspecifiedUnknown())
GetTriple().setOS(other.GetTriple().getOS());
if (GetTriple().getArch() == llvm::Triple::UnknownArch)
GetTriple().setArch(other.GetTriple().getArch());
if (GetTriple().getEnvironment() == llvm::Triple::UnknownEnvironment &&
!TripleVendorWasSpecified()) {
if (other.TripleVendorWasSpecified())
GetTriple().setEnvironment(other.GetTriple().getEnvironment());
}
// If this and other are both arm ArchSpecs and this ArchSpec is a generic
// "some kind of arm"
// spec but the other ArchSpec is a specific arm core, adopt the specific arm
// core.
if (GetTriple().getArch() == llvm::Triple::arm &&
other.GetTriple().getArch() == llvm::Triple::arm &&
IsCompatibleMatch(other) && GetCore() == ArchSpec::eCore_arm_generic &&
other.GetCore() != ArchSpec::eCore_arm_generic) {
m_core = other.GetCore();
CoreUpdated(true);
}
Don't stomp the triple when loading a PECOFF target. 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
2015-01-23 02:59:05 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
bool ArchSpec::SetArchitecture(ArchitectureType arch_type, uint32_t cpu,
uint32_t sub, uint32_t os) {
m_core = kCore_invalid;
bool update_triple = true;
const ArchDefinition *arch_def = FindArchDefinition(arch_type);
if (arch_def) {
const ArchDefinitionEntry *arch_def_entry =
FindArchDefinitionEntry(arch_def, cpu, sub);
if (arch_def_entry) {
const CoreDefinition *core_def = FindCoreDefinition(arch_def_entry->core);
if (core_def) {
m_core = core_def->core;
update_triple = false;
// Always use the architecture name because it might be more descriptive
// than the architecture enum ("armv7" -> llvm::Triple::arm).
m_triple.setArchName(llvm::StringRef(core_def->name));
if (arch_type == eArchTypeMachO) {
m_triple.setVendor(llvm::Triple::Apple);
// Don't set the OS. It could be simulator, macosx, ios, watchos,
// tvos. We could
// get close with the cpu type - but we can't get it right all of the
// time. Better
// to leave this unset so other sections of code will set it when they
// have more
// information.
// NB: don't call m_triple.setOS (llvm::Triple::UnknownOS). That sets
// the OSName to
// "unknown" and the ArchSpec::TripleVendorWasSpecified() method says
// that any
// OSName setting means it was specified.
} else if (arch_type == eArchTypeELF) {
switch (os) {
case llvm::ELF::ELFOSABI_AIX:
m_triple.setOS(llvm::Triple::OSType::AIX);
break;
case llvm::ELF::ELFOSABI_FREEBSD:
m_triple.setOS(llvm::Triple::OSType::FreeBSD);
break;
case llvm::ELF::ELFOSABI_GNU:
m_triple.setOS(llvm::Triple::OSType::Linux);
break;
case llvm::ELF::ELFOSABI_NETBSD:
m_triple.setOS(llvm::Triple::OSType::NetBSD);
break;
case llvm::ELF::ELFOSABI_OPENBSD:
m_triple.setOS(llvm::Triple::OSType::OpenBSD);
break;
case llvm::ELF::ELFOSABI_SOLARIS:
m_triple.setOS(llvm::Triple::OSType::Solaris);
break;
}
Set the correct triple when creating an ArchSpec for Windows. Patch by Walter Erquinigo Differential Revision: https://reviews.llvm.org/D24283 llvm-svn: 281765
2016-09-17 03:09:19 +08:00
} else if (arch_type == eArchTypeCOFF && os == llvm::Triple::Win32) {
m_triple.setVendor(llvm::Triple::PC);
m_triple.setOS(llvm::Triple::Win32);
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
} else {
m_triple.setVendor(llvm::Triple::UnknownVendor);
m_triple.setOS(llvm::Triple::UnknownOS);
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
// Fall back onto setting the machine type if the arch by name failed...
if (m_triple.getArch() == llvm::Triple::UnknownArch)
m_triple.setArch(core_def->machine);
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
CoreUpdated(update_triple);
return IsValid();
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
uint32_t ArchSpec::GetMinimumOpcodeByteSize() const {
const CoreDefinition *core_def = FindCoreDefinition(m_core);
if (core_def)
return core_def->min_opcode_byte_size;
return 0;
Added the ability to get the min and max instruction byte size for an architecture into ArchSpec: uint32_t ArchSpec::GetMinimumOpcodeByteSize() const; uint32_t ArchSpec::GetMaximumOpcodeByteSize() const; Added an AddressClass to the Instruction class in Disassembler.h. This allows decoded instructions to know know if they are code, code with alternate ISA (thumb), or even data which can be mixed into code. The instruction does have an address, but it is a good idea to cache this value so we don't have to look it up more than once. Fixed an issue in Opcode::SetOpcodeBytes() where the length wasn't getting set. Changed: bool SymbolContextList::AppendIfUnique (const SymbolContext& sc); To: bool SymbolContextList::AppendIfUnique (const SymbolContext& sc, bool merge_symbol_into_function); This function was typically being used when looking up functions and symbols. Now if you lookup a function, then find the symbol, they can be merged into the same symbol context and not cause multiple symbol contexts to appear in a symbol context list that describes the same function. Fixed the SymbolContext not equal operator which was causing mixed mode disassembly to not work ("disassembler --mixed --name main"). Modified the disassembler classes to know about the fact we know, for a given architecture, what the min and max opcode byte sizes are. The InstructionList class was modified to return the max opcode byte size for all of the instructions in its list. These two fixes means when disassemble a list of instructions and dump them and show the opcode bytes, we can format the output more intelligently when showing opcode bytes. This affects any architectures that have varying opcode byte sizes (x86_64 and i386). Knowing the max opcode byte size also helps us to be able to disassemble N instructions without having to re-read data if we didn't read enough bytes. Added the ability to set the architecture for the disassemble command. This means you can easily cross disassemble data for any supported architecture. I also added the ability to specify "thumb" as an architecture so that we can force disassembly into thumb mode when needed. In GDB this was done using a hack of specifying an odd address when disassembling. I don't want to repeat this hack in LLDB, so the auto detection between ARM and thumb is failing, just specify thumb when disassembling: (lldb) disassemble --arch thumb --name main You can also have data in say an x86_64 file executable and disassemble data as any other supported architecture: % lldb a.out Current executable set to 'a.out' (x86_64). (lldb) b main (lldb) run (lldb) disassemble --arch thumb --count 2 --start-address 0x0000000100001080 --bytes 0x100001080: 0xb580 push {r7, lr} 0x100001082: 0xaf00 add r7, sp, #0 Fixed Target::ReadMemory(...) to be able to deal with Address argument object that isn't section offset. When an address object was supplied that was out on the heap or stack, target read memory would fail. Disassembly uses Target::ReadMemory(...), and the example above where we disassembler thumb opcodes in an x86 binary was failing do to this bug. llvm-svn: 128347
2011-03-27 03:14:58 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
uint32_t ArchSpec::GetMaximumOpcodeByteSize() const {
const CoreDefinition *core_def = FindCoreDefinition(m_core);
if (core_def)
return core_def->max_opcode_byte_size;
return 0;
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
bool ArchSpec::IsExactMatch(const ArchSpec &rhs) const {
return IsEqualTo(rhs, true);
Add new ArchSpec methods, IsCompatibleMatch() and IsExactMatch(). The operator== method is a synonym for IsExactMatch(). The essential difference between these two is that IsCompatibleMatch() will say that armv7 and armv7s are compatible and return true. IsExactMatch() will say that armv7 and armv7s are not a match. An armv7s cpu can run either generic armv7 binaries or armv7s binaries (the latter being tuned for it). When we're picking the slice of a universal Mach-O file to load in an armv7s Target, we need to be able to first look for an exact cpu subtype match (armv7s == armv7s) and failing that, looking for a slice with a compatible architecture. Update ObjectContainerUniversalMachO::GetObjectFile to prefer an exact match of the cpu type, falling back to a compatible match if necessary. <rdar://problem/12593515> llvm-svn: 167365
2012-11-04 11:20:05 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
bool ArchSpec::IsCompatibleMatch(const ArchSpec &rhs) const {
return IsEqualTo(rhs, false);
Add new ArchSpec methods, IsCompatibleMatch() and IsExactMatch(). The operator== method is a synonym for IsExactMatch(). The essential difference between these two is that IsCompatibleMatch() will say that armv7 and armv7s are compatible and return true. IsExactMatch() will say that armv7 and armv7s are not a match. An armv7s cpu can run either generic armv7 binaries or armv7s binaries (the latter being tuned for it). When we're picking the slice of a universal Mach-O file to load in an armv7s Target, we need to be able to first look for an exact cpu subtype match (armv7s == armv7s) and failing that, looking for a slice with a compatible architecture. Update ObjectContainerUniversalMachO::GetObjectFile to prefer an exact match of the cpu type, falling back to a compatible match if necessary. <rdar://problem/12593515> llvm-svn: 167365
2012-11-04 11:20:05 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
static bool isCompatibleEnvironment(llvm::Triple::EnvironmentType lhs,
llvm::Triple::EnvironmentType rhs) {
if (lhs == rhs)
return true;
// If any of the environment is unknown then they are compatible
if (lhs == llvm::Triple::UnknownEnvironment ||
rhs == llvm::Triple::UnknownEnvironment)
return true;
// If one of the environment is Android and the other one is EABI then they
// are considered to
// be compatible. This is required as a workaround for shared libraries
// compiled for Android
// without the NOTE section indicating that they are using the Android ABI.
if ((lhs == llvm::Triple::Android && rhs == llvm::Triple::EABI) ||
(rhs == llvm::Triple::Android && lhs == llvm::Triple::EABI) ||
(lhs == llvm::Triple::GNUEABI && rhs == llvm::Triple::EABI) ||
(rhs == llvm::Triple::GNUEABI && lhs == llvm::Triple::EABI) ||
(lhs == llvm::Triple::GNUEABIHF && rhs == llvm::Triple::EABIHF) ||
(rhs == llvm::Triple::GNUEABIHF && lhs == llvm::Triple::EABIHF))
return true;
return false;
}
Fix ARM attribute parsing for Android after rL267291 Differential revision: http://reviews.llvm.org/D19480 llvm-svn: 267422
2016-04-25 23:51:45 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
bool ArchSpec::IsEqualTo(const ArchSpec &rhs, bool exact_match) const {
// explicitly ignoring m_distribution_id in this method.
Fix ARM attribute parsing for Android after rL267291 Differential revision: http://reviews.llvm.org/D19480 llvm-svn: 267422
2016-04-25 23:51:45 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
if (GetByteOrder() != rhs.GetByteOrder())
Fix ARM attribute parsing for Android after rL267291 Differential revision: http://reviews.llvm.org/D19480 llvm-svn: 267422
2016-04-25 23:51:45 +08:00
return false;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
const ArchSpec::Core lhs_core = GetCore();
const ArchSpec::Core rhs_core = rhs.GetCore();
const bool core_match = cores_match(lhs_core, rhs_core, true, exact_match);
Added distribution info to ArchSpec and qHostInfo message. ArchSpec now contains an optional distribution_id, with getters and setters. Host::GetArchitecture () sets it on non-Apple platforms using Host::GetDistributionId (). The distribution_id is ignored during ArchSpec comparisons. The gdb remote qHostInfo message transmits it, if set, via the distribution_id={id-value} key/value pair. Updated gdb remote docs to reflect this change. As before, GetDistributionId () returns nothing on non-Linux platforms at this time. On Linux, it is returned only if the lsb_platform command is installed (in /bin or /usr/bin), and only if the distributor id key is returned by 'lsb_platform -i'. This id is lowercased, and whitespace is replaced with underscores. llvm-svn: 199539
2014-01-18 11:02:39 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
if (core_match) {
const llvm::Triple &lhs_triple = GetTriple();
const llvm::Triple &rhs_triple = rhs.GetTriple();
const llvm::Triple::VendorType lhs_triple_vendor = lhs_triple.getVendor();
const llvm::Triple::VendorType rhs_triple_vendor = rhs_triple.getVendor();
if (lhs_triple_vendor != rhs_triple_vendor) {
const bool rhs_vendor_specified = rhs.TripleVendorWasSpecified();
const bool lhs_vendor_specified = TripleVendorWasSpecified();
// Both architectures had the vendor specified, so if they aren't
// equal then we return false
if (rhs_vendor_specified && lhs_vendor_specified)
Add new ArchSpec methods, IsCompatibleMatch() and IsExactMatch(). The operator== method is a synonym for IsExactMatch(). The essential difference between these two is that IsCompatibleMatch() will say that armv7 and armv7s are compatible and return true. IsExactMatch() will say that armv7 and armv7s are not a match. An armv7s cpu can run either generic armv7 binaries or armv7s binaries (the latter being tuned for it). When we're picking the slice of a universal Mach-O file to load in an armv7s Target, we need to be able to first look for an exact cpu subtype match (armv7s == armv7s) and failing that, looking for a slice with a compatible architecture. Update ObjectContainerUniversalMachO::GetObjectFile to prefer an exact match of the cpu type, falling back to a compatible match if necessary. <rdar://problem/12593515> llvm-svn: 167365
2012-11-04 11:20:05 +08:00
return false;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
// Only fail if both vendor types are not unknown
if (lhs_triple_vendor != llvm::Triple::UnknownVendor &&
rhs_triple_vendor != llvm::Triple::UnknownVendor)
return false;
Add new ArchSpec methods, IsCompatibleMatch() and IsExactMatch(). The operator== method is a synonym for IsExactMatch(). The essential difference between these two is that IsCompatibleMatch() will say that armv7 and armv7s are compatible and return true. IsExactMatch() will say that armv7 and armv7s are not a match. An armv7s cpu can run either generic armv7 binaries or armv7s binaries (the latter being tuned for it). When we're picking the slice of a universal Mach-O file to load in an armv7s Target, we need to be able to first look for an exact cpu subtype match (armv7s == armv7s) and failing that, looking for a slice with a compatible architecture. Update ObjectContainerUniversalMachO::GetObjectFile to prefer an exact match of the cpu type, falling back to a compatible match if necessary. <rdar://problem/12593515> llvm-svn: 167365
2012-11-04 11:20:05 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
const llvm::Triple::OSType lhs_triple_os = lhs_triple.getOS();
const llvm::Triple::OSType rhs_triple_os = rhs_triple.getOS();
if (lhs_triple_os != rhs_triple_os) {
const bool rhs_os_specified = rhs.TripleOSWasSpecified();
const bool lhs_os_specified = TripleOSWasSpecified();
// Both architectures had the OS specified, so if they aren't
// equal then we return false
if (rhs_os_specified && lhs_os_specified)
return false;
// Only fail if both os types are not unknown
if (lhs_triple_os != llvm::Triple::UnknownOS &&
rhs_triple_os != llvm::Triple::UnknownOS)
return false;
}
const llvm::Triple::EnvironmentType lhs_triple_env =
lhs_triple.getEnvironment();
const llvm::Triple::EnvironmentType rhs_triple_env =
rhs_triple.getEnvironment();
if (!isCompatibleEnvironment(lhs_triple_env, rhs_triple_env))
return false;
return true;
}
return false;
Add new ArchSpec methods, IsCompatibleMatch() and IsExactMatch(). The operator== method is a synonym for IsExactMatch(). The essential difference between these two is that IsCompatibleMatch() will say that armv7 and armv7s are compatible and return true. IsExactMatch() will say that armv7 and armv7s are not a match. An armv7s cpu can run either generic armv7 binaries or armv7s binaries (the latter being tuned for it). When we're picking the slice of a universal Mach-O file to load in an armv7s Target, we need to be able to first look for an exact cpu subtype match (armv7s == armv7s) and failing that, looking for a slice with a compatible architecture. Update ObjectContainerUniversalMachO::GetObjectFile to prefer an exact match of the cpu type, falling back to a compatible match if necessary. <rdar://problem/12593515> llvm-svn: 167365
2012-11-04 11:20:05 +08:00
}
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
//===----------------------------------------------------------------------===//
// Helper methods.
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
void ArchSpec::CoreUpdated(bool update_triple) {
const CoreDefinition *core_def = FindCoreDefinition(m_core);
if (core_def) {
if (update_triple)
m_triple = llvm::Triple(core_def->name, "unknown", "unknown");
m_byte_order = core_def->default_byte_order;
} else {
if (update_triple)
m_triple = llvm::Triple();
m_byte_order = eByteOrderInvalid;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Abtracted all mach-o and ELF out of ArchSpec. This patch is a modified form of Stephen Wilson's idea (thanks for the input Stephen!). What I ended up doing was: - Got rid of ArchSpec::CPU (which was a generic CPU enumeration that mimics the contents of llvm::Triple::ArchType). We now rely upon the llvm::Triple to give us the machine type from llvm::Triple::ArchType. - There is a new ArchSpec::Core definition which further qualifies the CPU core we are dealing with into a single enumeration. If you need support for a new Core and want to debug it in LLDB, it must be added to this list. In the future we can allow for dynamic core registration, but for now it is hard coded. - The ArchSpec can now be initialized with a llvm::Triple or with a C string that represents the triple (it can just be an arch still like "i386"). - The ArchSpec can still initialize itself with a architecture type -- mach-o with cpu type and subtype, or ELF with e_machine + e_flags -- and this will then get translated into the internal llvm::Triple::ArchSpec + ArchSpec::Core. The mach-o cpu type and subtype can be accessed using the getter functions: uint32_t ArchSpec::GetMachOCPUType () const; uint32_t ArchSpec::GetMachOCPUSubType () const; But these functions are just converting out internal llvm::Triple::ArchSpec + ArchSpec::Core back into mach-o. Same goes for ELF. All code has been updated to deal with the changes. This should abstract us until later when the llvm::TargetSpec stuff gets finalized and we can then adopt it. llvm-svn: 126278
2011-02-23 08:35:02 +08:00
//===----------------------------------------------------------------------===//
// Operators.
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
static bool cores_match(const ArchSpec::Core core1, const ArchSpec::Core core2,
bool try_inverse, bool enforce_exact_match) {
if (core1 == core2)
return true;
switch (core1) {
case ArchSpec::kCore_any:
return true;
case ArchSpec::eCore_arm_generic:
if (enforce_exact_match)
break;
LLVM_FALLTHROUGH;
case ArchSpec::kCore_arm_any:
if (core2 >= ArchSpec::kCore_arm_first && core2 <= ArchSpec::kCore_arm_last)
return true;
if (core2 >= ArchSpec::kCore_thumb_first &&
core2 <= ArchSpec::kCore_thumb_last)
return true;
if (core2 == ArchSpec::kCore_arm_any)
return true;
break;
case ArchSpec::kCore_x86_32_any:
if ((core2 >= ArchSpec::kCore_x86_32_first &&
core2 <= ArchSpec::kCore_x86_32_last) ||
(core2 == ArchSpec::kCore_x86_32_any))
return true;
break;
case ArchSpec::kCore_x86_64_any:
if ((core2 >= ArchSpec::kCore_x86_64_first &&
core2 <= ArchSpec::kCore_x86_64_last) ||
(core2 == ArchSpec::kCore_x86_64_any))
return true;
break;
case ArchSpec::kCore_ppc_any:
if ((core2 >= ArchSpec::kCore_ppc_first &&
core2 <= ArchSpec::kCore_ppc_last) ||
(core2 == ArchSpec::kCore_ppc_any))
return true;
break;
case ArchSpec::kCore_ppc64_any:
if ((core2 >= ArchSpec::kCore_ppc64_first &&
core2 <= ArchSpec::kCore_ppc64_last) ||
(core2 == ArchSpec::kCore_ppc64_any))
return true;
break;
case ArchSpec::eCore_arm_armv6m:
if (!enforce_exact_match) {
if (core2 == ArchSpec::eCore_arm_generic)
Add new ArchSpec methods, IsCompatibleMatch() and IsExactMatch(). The operator== method is a synonym for IsExactMatch(). The essential difference between these two is that IsCompatibleMatch() will say that armv7 and armv7s are compatible and return true. IsExactMatch() will say that armv7 and armv7s are not a match. An armv7s cpu can run either generic armv7 binaries or armv7s binaries (the latter being tuned for it). When we're picking the slice of a universal Mach-O file to load in an armv7s Target, we need to be able to first look for an exact cpu subtype match (armv7s == armv7s) and failing that, looking for a slice with a compatible architecture. Update ObjectContainerUniversalMachO::GetObjectFile to prefer an exact match of the cpu type, falling back to a compatible match if necessary. <rdar://problem/12593515> llvm-svn: 167365
2012-11-04 11:20:05 +08:00
return true;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
try_inverse = false;
if (core2 == ArchSpec::eCore_arm_armv7)
return true;
if (core2 == ArchSpec::eCore_arm_armv6m)
return true;
}
break;
case ArchSpec::kCore_hexagon_any:
if ((core2 >= ArchSpec::kCore_hexagon_first &&
core2 <= ArchSpec::kCore_hexagon_last) ||
(core2 == ArchSpec::kCore_hexagon_any))
return true;
break;
// v. https://en.wikipedia.org/wiki/ARM_Cortex-M#Silicon_customization
// Cortex-M0 - ARMv6-M - armv6m
// Cortex-M3 - ARMv7-M - armv7m
// Cortex-M4 - ARMv7E-M - armv7em
case ArchSpec::eCore_arm_armv7em:
if (!enforce_exact_match) {
if (core2 == ArchSpec::eCore_arm_generic)
return true;
if (core2 == ArchSpec::eCore_arm_armv7m)
return true;
if (core2 == ArchSpec::eCore_arm_armv6m)
return true;
if (core2 == ArchSpec::eCore_arm_armv7)
return true;
try_inverse = true;
}
break;
// v. https://en.wikipedia.org/wiki/ARM_Cortex-M#Silicon_customization
// Cortex-M0 - ARMv6-M - armv6m
// Cortex-M3 - ARMv7-M - armv7m
// Cortex-M4 - ARMv7E-M - armv7em
case ArchSpec::eCore_arm_armv7m:
if (!enforce_exact_match) {
if (core2 == ArchSpec::eCore_arm_generic)
return true;
if (core2 == ArchSpec::eCore_arm_armv6m)
return true;
if (core2 == ArchSpec::eCore_arm_armv7)
return true;
if (core2 == ArchSpec::eCore_arm_armv7em)
return true;
try_inverse = true;
}
break;
Add new ArchSpec methods, IsCompatibleMatch() and IsExactMatch(). The operator== method is a synonym for IsExactMatch(). The essential difference between these two is that IsCompatibleMatch() will say that armv7 and armv7s are compatible and return true. IsExactMatch() will say that armv7 and armv7s are not a match. An armv7s cpu can run either generic armv7 binaries or armv7s binaries (the latter being tuned for it). When we're picking the slice of a universal Mach-O file to load in an armv7s Target, we need to be able to first look for an exact cpu subtype match (armv7s == armv7s) and failing that, looking for a slice with a compatible architecture. Update ObjectContainerUniversalMachO::GetObjectFile to prefer an exact match of the cpu type, falling back to a compatible match if necessary. <rdar://problem/12593515> llvm-svn: 167365
2012-11-04 11:20:05 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
case ArchSpec::eCore_arm_armv7f:
case ArchSpec::eCore_arm_armv7k:
case ArchSpec::eCore_arm_armv7s:
if (!enforce_exact_match) {
if (core2 == ArchSpec::eCore_arm_generic)
<rdar://problem/11358639> Switch over to the "*-apple-macosx" for desktop and "*-apple-ios" for iOS triples. Also make the selection process for auto selecting platforms based off of an arch much better. llvm-svn: 156354
2012-05-08 09:45:38 +08:00
return true;
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
if (core2 == ArchSpec::eCore_arm_armv7)
return true;
try_inverse = false;
}
break;
<rdar://problem/11358639> Switch over to the "*-apple-macosx" for desktop and "*-apple-ios" for iOS triples. Also make the selection process for auto selecting platforms based off of an arch much better. llvm-svn: 156354
2012-05-08 09:45:38 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
case ArchSpec::eCore_x86_64_x86_64h:
if (!enforce_exact_match) {
try_inverse = false;
if (core2 == ArchSpec::eCore_x86_64_x86_64)
return true;
}
break;
lldb - towards AArch64 being recognised as platform architecture See http://reviews.llvm.org/D4381. Change by Paul Osmialowski. llvm-svn: 216668
2014-08-28 22:32:43 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
case ArchSpec::eCore_arm_armv8:
if (!enforce_exact_match) {
if (core2 == ArchSpec::eCore_arm_arm64)
return true;
if (core2 == ArchSpec::eCore_arm_aarch64)
return true;
try_inverse = false;
}
break;
[LLDB][MIPS] Add mips cores in cores_match () in ArchSpec 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
2015-07-13 17:52:06 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
case ArchSpec::eCore_arm_aarch64:
if (!enforce_exact_match) {
if (core2 == ArchSpec::eCore_arm_arm64)
return true;
if (core2 == ArchSpec::eCore_arm_armv8)
return true;
try_inverse = false;
}
break;
[LLDB][MIPS] Add mips cores in cores_match () in ArchSpec 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
2015-07-13 17:52:06 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
case ArchSpec::eCore_arm_arm64:
if (!enforce_exact_match) {
if (core2 == ArchSpec::eCore_arm_aarch64)
return true;
if (core2 == ArchSpec::eCore_arm_armv8)
return true;
try_inverse = false;
}
break;
[LLDB][MIPS] Add mips cores in cores_match () in ArchSpec 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
2015-07-13 17:52:06 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
case ArchSpec::eCore_mips32:
if (!enforce_exact_match) {
if (core2 >= ArchSpec::kCore_mips32_first &&
core2 <= ArchSpec::kCore_mips32_last)
return true;
try_inverse = false;
}
break;
[LLDB][MIPS] Add mips cores in cores_match () in ArchSpec 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
2015-07-13 17:52:06 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
case ArchSpec::eCore_mips32el:
if (!enforce_exact_match) {
if (core2 >= ArchSpec::kCore_mips32el_first &&
core2 <= ArchSpec::kCore_mips32el_last)
return true;
try_inverse = false;
}
break;
[MIPS][lldb-server] Add 32-bit register context and read/write FP registers 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
2015-06-03 18:14:24 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
case ArchSpec::eCore_mips64:
if (!enforce_exact_match) {
if (core2 >= ArchSpec::kCore_mips32_first &&
core2 <= ArchSpec::kCore_mips32_last)
return true;
if (core2 >= ArchSpec::kCore_mips64_first &&
core2 <= ArchSpec::kCore_mips64_last)
return true;
try_inverse = false;
}
break;
[MIPS][lldb-server] Add 32-bit register context and read/write FP registers 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
2015-06-03 18:14:24 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
case ArchSpec::eCore_mips64el:
if (!enforce_exact_match) {
if (core2 >= ArchSpec::kCore_mips32el_first &&
core2 <= ArchSpec::kCore_mips32el_last)
return true;
if (core2 >= ArchSpec::kCore_mips64el_first &&
core2 <= ArchSpec::kCore_mips64el_last)
return true;
try_inverse = false;
}
break;
[LLDB][MIPS] Add mips cores in cores_match () in ArchSpec 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
2015-07-13 17:52:06 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
case ArchSpec::eCore_mips64r2:
case ArchSpec::eCore_mips64r3:
case ArchSpec::eCore_mips64r5:
if (!enforce_exact_match) {
if (core2 >= ArchSpec::kCore_mips32_first && core2 <= (core1 - 10))
return true;
if (core2 >= ArchSpec::kCore_mips64_first && core2 <= (core1 - 1))
return true;
try_inverse = false;
}
break;
[LLDB][MIPS] Add mips cores in cores_match () in ArchSpec 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
2015-07-13 17:52:06 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
case ArchSpec::eCore_mips64r2el:
case ArchSpec::eCore_mips64r3el:
case ArchSpec::eCore_mips64r5el:
if (!enforce_exact_match) {
if (core2 >= ArchSpec::kCore_mips32el_first && core2 <= (core1 - 10))
return true;
if (core2 >= ArchSpec::kCore_mips64el_first && core2 <= (core1 - 1))
return true;
try_inverse = false;
}
break;
[LLDB][MIPS] Add mips cores in cores_match () in ArchSpec 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
2015-07-13 17:52:06 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
case ArchSpec::eCore_mips32r2:
case ArchSpec::eCore_mips32r3:
case ArchSpec::eCore_mips32r5:
if (!enforce_exact_match) {
if (core2 >= ArchSpec::kCore_mips32_first && core2 <= core1)
return true;
}
break;
[LLDB][MIPS] Add mips cores in cores_match () in ArchSpec 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
2015-07-13 17:52:06 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
case ArchSpec::eCore_mips32r2el:
case ArchSpec::eCore_mips32r3el:
case ArchSpec::eCore_mips32r5el:
if (!enforce_exact_match) {
if (core2 >= ArchSpec::kCore_mips32el_first && core2 <= core1)
return true;
}
break;
[LLDB][MIPS] Add mips cores in cores_match () in ArchSpec 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
2015-07-13 17:52:06 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
case ArchSpec::eCore_mips32r6:
if (!enforce_exact_match) {
if (core2 == ArchSpec::eCore_mips32 || core2 == ArchSpec::eCore_mips32r6)
return true;
}
break;
[LLDB][MIPS] Add mips cores in cores_match () in ArchSpec 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
2015-07-13 17:52:06 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
case ArchSpec::eCore_mips32r6el:
if (!enforce_exact_match) {
if (core2 == ArchSpec::eCore_mips32el ||
core2 == ArchSpec::eCore_mips32r6el)
return true;
<rdar://problem/11358639> Switch over to the "*-apple-macosx" for desktop and "*-apple-ios" for iOS triples. Also make the selection process for auto selecting platforms based off of an arch much better. llvm-svn: 156354
2012-05-08 09:45:38 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
break;
case ArchSpec::eCore_mips64r6:
if (!enforce_exact_match) {
if (core2 == ArchSpec::eCore_mips32 || core2 == ArchSpec::eCore_mips32r6)
return true;
if (core2 == ArchSpec::eCore_mips64 || core2 == ArchSpec::eCore_mips64r6)
return true;
}
break;
case ArchSpec::eCore_mips64r6el:
if (!enforce_exact_match) {
if (core2 == ArchSpec::eCore_mips32el ||
core2 == ArchSpec::eCore_mips32r6el)
return true;
if (core2 == ArchSpec::eCore_mips64el ||
core2 == ArchSpec::eCore_mips64r6el)
return true;
}
break;
default:
break;
}
if (try_inverse)
return cores_match(core2, core1, false, enforce_exact_match);
return false;
<rdar://problem/11358639> Switch over to the "*-apple-macosx" for desktop and "*-apple-ios" for iOS triples. Also make the selection process for auto selecting platforms based off of an arch much better. llvm-svn: 156354
2012-05-08 09:45:38 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
bool lldb_private::operator<(const ArchSpec &lhs, const ArchSpec &rhs) {
const ArchSpec::Core lhs_core = lhs.GetCore();
const ArchSpec::Core rhs_core = rhs.GetCore();
return lhs_core < rhs_core;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Handle thumb IT instructions correctly all the time. 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
2014-12-10 07:31:02 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
static void StopInfoOverrideCallbackTypeARM(lldb_private::Thread &thread) {
// We need to check if we are stopped in Thumb mode in a IT instruction
// and detect if the condition doesn't pass. If this is the case it means
// we won't actually execute this instruction. If this happens we need to
// clear the stop reason to no thread plans think we are stopped for a
// reason and the plans should keep going.
//
// We do this because when single stepping many ARM processes, debuggers
// often use the BVR/BCR registers that says "stop when the PC is not
// equal to its current value". This method of stepping means we can end
// up stopping on instructions inside an if/then block that wouldn't get
// executed. By fixing this we can stop the debugger from seeming like
// you stepped through both the "if" _and_ the "else" clause when source
// level stepping because the debugger stops regardless due to the BVR/BCR
// triggering a stop.
//
// It also means we can set breakpoints on instructions inside an an
// if/then block and correctly skip them if we use the BKPT instruction.
// The ARM and Thumb BKPT instructions are unconditional even when executed
// in a Thumb IT block.
//
// If your debugger inserts software traps in ARM/Thumb code, it will
// need to use 16 and 32 bit instruction for 16 and 32 bit thumb
// instructions respectively. If your debugger inserts a 16 bit thumb
// trap on top of a 32 bit thumb instruction for an opcode that is inside
// an if/then, it will change the it/then to conditionally execute your
// 16 bit trap and then cause your program to crash if it executes the
// trailing 16 bits (the second half of the 32 bit thumb instruction you
// partially overwrote).
RegisterContextSP reg_ctx_sp(thread.GetRegisterContext());
if (reg_ctx_sp) {
const uint32_t cpsr = reg_ctx_sp->GetFlags(0);
if (cpsr != 0) {
// Read the J and T bits to get the ISETSTATE
const uint32_t J = Bit32(cpsr, 24);
const uint32_t T = Bit32(cpsr, 5);
const uint32_t ISETSTATE = J << 1 | T;
if (ISETSTATE == 0) {
// NOTE: I am pretty sure we want to enable the code below
// that detects when we stop on an instruction in ARM mode
// that is conditional and the condition doesn't pass. This
// can happen if you set a breakpoint on an instruction that
// is conditional. We currently will _always_ stop on the
// instruction which is bad. You can also run into this while
// single stepping and you could appear to run code in the "if"
// and in the "else" clause because it would stop at all of the
// conditional instructions in both.
// In such cases, we really don't want to stop at this location.
// I will check with the lldb-dev list first before I enable this.
Handle thumb IT instructions correctly all the time. 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
2014-12-10 07:31:02 +08:00
#if 0
// ARM mode: check for condition on intsruction
const addr_t pc = reg_ctx_sp->GetPC();
Error error;
// If we fail to read the opcode we will get UINT64_MAX as the
// result in "opcode" which we can use to detect if we read a
// valid opcode.
const uint64_t opcode = thread.GetProcess()->ReadUnsignedIntegerFromMemory(pc, 4, UINT64_MAX, error);
if (opcode <= UINT32_MAX)
{
const uint32_t condition = Bits32((uint32_t)opcode, 31, 28);
Fix Clang-tidy modernize-use-nullptr warnings in some files in source/Core; other minor fixes. llvm-svn: 262441
2016-03-02 09:09:03 +08:00
if (!ARMConditionPassed(condition, cpsr))
Handle thumb IT instructions correctly all the time. 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
2014-12-10 07:31:02 +08:00
{
// We ARE stopped on an ARM instruction whose condition doesn't
// pass so this instruction won't get executed.
// Regardless of why it stopped, we need to clear the stop info
thread.SetStopInfo (StopInfoSP());
}
}
#endif
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
} else if (ISETSTATE == 1) {
// Thumb mode
const uint32_t ITSTATE =
Bits32(cpsr, 15, 10) << 2 | Bits32(cpsr, 26, 25);
if (ITSTATE != 0) {
const uint32_t condition = Bits32(ITSTATE, 7, 4);
if (!ARMConditionPassed(condition, cpsr)) {
// We ARE stopped in a Thumb IT instruction on an instruction whose
// condition doesn't pass so this instruction won't get executed.
// Regardless of why it stopped, we need to clear the stop info
thread.SetStopInfo(StopInfoSP());
}
Handle thumb IT instructions correctly all the time. 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
2014-12-10 07:31:02 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
Handle thumb IT instructions correctly all the time. 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
2014-12-10 07:31:02 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
Handle thumb IT instructions correctly all the time. 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
2014-12-10 07:31:02 +08:00
}
ArchSpec::StopInfoOverrideCallbackType
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
ArchSpec::GetStopInfoOverrideCallback() const {
const llvm::Triple::ArchType machine = GetMachine();
if (machine == llvm::Triple::arm)
return StopInfoOverrideCallbackTypeARM;
return nullptr;
Handle thumb IT instructions correctly all the time. 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
2014-12-10 07:31:02 +08:00
}
ArchSpec: fix unintentional promotion of unspecified unknowns to specified 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
2015-10-14 07:41:19 +08:00
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
bool ArchSpec::IsFullySpecifiedTriple() const {
const auto &user_specified_triple = GetTriple();
bool user_triple_fully_specified = false;
if ((user_specified_triple.getOS() != llvm::Triple::UnknownOS) ||
TripleOSWasSpecified()) {
if ((user_specified_triple.getVendor() != llvm::Triple::UnknownVendor) ||
TripleVendorWasSpecified()) {
const unsigned unspecified = 0;
if (user_specified_triple.getOSMajorVersion() != unspecified) {
user_triple_fully_specified = true;
}
A little more careful handling of platforms and unspecified unknown 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
2015-11-06 09:43:36 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
return user_triple_fully_specified;
A little more careful handling of platforms and unspecified unknown 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
2015-11-06 09:43:36 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
void ArchSpec::PiecewiseTripleCompare(
const ArchSpec &other, bool &arch_different, bool &vendor_different,
bool &os_different, bool &os_version_different, bool &env_different) {
const llvm::Triple &me(GetTriple());
const llvm::Triple &them(other.GetTriple());
arch_different = (me.getArch() != them.getArch());
vendor_different = (me.getVendor() != them.getVendor());
os_different = (me.getOS() != them.getOS());
os_version_different = (me.getOSMajorVersion() != them.getOSMajorVersion());
env_different = (me.getEnvironment() != them.getEnvironment());
A little more careful handling of platforms and unspecified unknown 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
2015-11-06 09:43:36 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
bool ArchSpec::IsAlwaysThumbInstructions() const {
std::string Error;
if (GetTriple().getArch() == llvm::Triple::arm ||
GetTriple().getArch() == llvm::Triple::thumb) {
// v. https://en.wikipedia.org/wiki/ARM_Cortex-M
//
// Cortex-M0 through Cortex-M7 are ARM processor cores which can only
// execute thumb instructions. We map the cores to arch names like this:
//
// Cortex-M0, Cortex-M0+, Cortex-M1: armv6m
// Cortex-M3: armv7m
// Cortex-M4, Cortex-M7: armv7em
if (GetCore() == ArchSpec::Core::eCore_arm_armv7m ||
GetCore() == ArchSpec::Core::eCore_arm_armv7em ||
GetCore() == ArchSpec::Core::eCore_arm_armv6m) {
return true;
Consolidate the knowledge of what arm cores are always executing 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
2016-04-05 13:01:30 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
}
return false;
Consolidate the knowledge of what arm cores are always executing 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
2016-04-05 13:01:30 +08:00
}
*** This commit represents a complete reformatting of the LLDB source code *** to conform to clang-format’s LLVM style. This kind of mass change has *** two obvious implications: Firstly, merging this particular commit into a downstream fork may be a huge effort. Alternatively, it may be worth merging all changes up to this commit, performing the same reformatting operation locally, and then discarding the merge for this particular commit. The commands used to accomplish this reformatting were as follows (with current working directory as the root of the repository): find . \( -iname "*.c" -or -iname "*.cpp" -or -iname "*.h" -or -iname "*.mm" \) -exec clang-format -i {} + find . -iname "*.py" -exec autopep8 --in-place --aggressive --aggressive {} + ; The version of clang-format used was 3.9.0, and autopep8 was 1.2.4. Secondly, “blame” style tools will generally point to this commit instead of a meaningful prior commit. There are alternatives available that will attempt to look through this change and find the appropriate prior commit. YMMV. llvm-svn: 280751
2016-09-07 04:57:50 +08:00
void ArchSpec::DumpTriple(Stream &s) const {
const llvm::Triple &triple = GetTriple();
llvm::StringRef arch_str = triple.getArchName();
llvm::StringRef vendor_str = triple.getVendorName();
llvm::StringRef os_str = triple.getOSName();
llvm::StringRef environ_str = triple.getEnvironmentName();
s.Printf("%s-%s-%s", arch_str.empty() ? "*" : arch_str.str().c_str(),
vendor_str.empty() ? "*" : vendor_str.str().c_str(),
os_str.empty() ? "*" : os_str.str().c_str());
if (!environ_str.empty())
s.Printf("-%s", environ_str.str().c_str());
ArchSpec: fix unintentional promotion of unspecified unknowns to specified 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
2015-10-14 07:41:19 +08:00
}