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

Ignoring revisions in .git-blame-ignore-revs. Click here to bypass and see the normal blame view.

1466 lines
51 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++ -*-===//
//
Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. llvm-svn: 351636
2019-01-19 16:50:56 +08:00
// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
// See https://llvm.org/LICENSE.txt for license information.
// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
//
//===----------------------------------------------------------------------===//
Move ArchSpec to the Utility module The rationale here is that ArchSpec is used throughout the codebase, including in places which should not depend on the rest of the code in the Core module. This commit touches many files, but most of it is just renaming of #include lines. In a couple of cases, I removed the #include ArchSpec line altogether, as the file was not using it. In one or two places, this necessitated adding other #includes like lldb-private-defines.h. llvm-svn: 318048
2017-11-14 00:16:33 +08:00
#include "lldb/Utility/ArchSpec.h"
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
Add logging when ArchSpec::SetArchitecture is given a cputype and cpusubtype that don't map to any known core definition. <rdar://problem/39779398> llvm-svn: 331236
2018-05-01 08:05:54 +08:00
#include "lldb/Utility/Log.h"
Move StringList from Core -> Utility. llvm-svn: 298412
2017-03-22 02:25:04 +08:00
#include "lldb/Utility/StringList.h"
Remove comments after header includes. This patch removes the comments following the header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdates and burdensome to maintain. Differential revision: https://reviews.llvm.org/D54385 llvm-svn: 346625
2018-11-12 07:16:43 +08:00
#include "lldb/lldb-defines.h"
iwyu fixes for lldbCore. This adjusts header file includes for headers and source files in Core. In doing so, one dependency cycle is eliminated because all the includes from Core to that project were dead includes anyway. In places where some files in other projects were only compiling due to a transitive include from another header, fixups have been made so that those files also include the header they need. Tested on Windows and Linux, and plan to address failures on OSX and FreeBSD after watching the bots. llvm-svn: 299714
2017-04-07 05:28:29 +08:00
#include "llvm/ADT/STLExtras.h"
Move Object format code to lib/BinaryFormat. This creates a new library called BinaryFormat that has all of the headers from llvm/Support containing structure and layout definitions for various types of binary formats like dwarf, coff, elf, etc as well as the code for identifying a file from its magic. Differential Revision: https://reviews.llvm.org/D33843 llvm-svn: 304864
2017-06-07 11:48:56 +08:00
#include "llvm/BinaryFormat/COFF.h"
#include "llvm/BinaryFormat/ELF.h"
Remove comments after header includes. This patch removes the comments following the header includes. They were added after running IWYU over the LLDB codebase. However they add little value, are often outdates and burdensome to maintain. Differential revision: https://reviews.llvm.org/D54385 llvm-svn: 346625
2018-11-12 07:16:43 +08:00
#include "llvm/BinaryFormat/MachO.h"
#include "llvm/Support/Compiler.h"
iwyu fixes for lldbCore. This adjusts header file includes for headers and source files in Core. In doing so, one dependency cycle is eliminated because all the includes from Core to that project were dead includes anyway. In places where some files in other projects were only compiling due to a transitive include from another header, fixups have been made so that those files also include the header they need. Tested on Windows and Linux, and plan to address failures on OSX and FreeBSD after watching the bots. llvm-svn: 299714
2017-04-07 05:28:29 +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;
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
static bool cores_match(const ArchSpec::Core core1, const ArchSpec::Core core2,
bool try_inverse, bool enforce_exact_match);
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
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
struct CoreDefinition {
ByteOrder default_byte_order;
uint32_t addr_byte_size;
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
uint32_t min_opcode_byte_size;
uint32_t max_opcode_byte_size;
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
llvm::Triple::ArchType machine;
ArchSpec::Core core;
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
const char *const name;
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
} // 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
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
static const CoreDefinition g_core_definitions[] = {
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
{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"},
Handle all of the "thumb" target triple architecture variants that llvm handles. llvm-svn: 146746
2011-12-17 02:15:52 +08:00
{eByteOrderLittle, 4, 2, 4, llvm::Triple::arm, ArchSpec::eCore_arm_armv5e,
"armv5e"},
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
{eByteOrderLittle, 4, 2, 4, llvm::Triple::arm, ArchSpec::eCore_arm_armv5t,
"armv5t"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::arm, ArchSpec::eCore_arm_armv6,
"armv6"},
Add definitions for "armv6m", which indicates a Cortex-M0 processor. It uses the T16 and a few T32 instructions from the ARMv7-A ISA. <rdar://problem/15099306> llvm-svn: 191587
2013-09-28 07:21:54 +08:00
{eByteOrderLittle, 4, 2, 4, llvm::Triple::arm, ArchSpec::eCore_arm_armv6m,
"armv6m"},
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
{eByteOrderLittle, 4, 2, 4, llvm::Triple::arm, ArchSpec::eCore_arm_armv7,
"armv7"},
[LLDB] Add core definition for armv8l and armv7l This patch adds core definitions in lldb ArchSpecs for armv8l and armv7l cores. This was needed because on Linux running on 32-bit Arm v8 we are returned armv8l in case we are running 32-bit sysroot on 64bit kernel. In case of 32-bit kernel and 32-bit sysroot running on arm v8 hardware we are returned armv7l. This is quite common when we run 32 bit arm using docker container. Signed-off-by: Muhammad Omair Javaid <omair.javaid@linaro.org> Differential Revision: https://reviews.llvm.org/D69904
2019-11-13 08:30:25 +08:00
{eByteOrderLittle, 4, 2, 4, llvm::Triple::arm, ArchSpec::eCore_arm_armv7l,
"armv7l"},
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
{eByteOrderLittle, 4, 2, 4, llvm::Triple::arm, ArchSpec::eCore_arm_armv7f,
"armv7f"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::arm, ArchSpec::eCore_arm_armv7s,
"armv7s"},
Add recognition of two more armv7 variants, armv7m and armv7em. <rdar://problem/13361372> llvm-svn: 176674
2013-03-08 09:20:17 +08:00
{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"},
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
{eByteOrderLittle, 4, 2, 4, llvm::Triple::arm, ArchSpec::eCore_arm_xscale,
"xscale"},
Handle all of the "thumb" target triple architecture variants that llvm handles. llvm-svn: 146746
2011-12-17 02:15:52 +08:00
{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"},
Add definitions for "armv6m", which indicates a Cortex-M0 processor. It uses the T16 and a few T32 instructions from the ARMv7-A ISA. <rdar://problem/15099306> llvm-svn: 191587
2013-09-28 07:21:54 +08:00
{eByteOrderLittle, 4, 2, 4, llvm::Triple::thumb, ArchSpec::eCore_thumbv6m,
"thumbv6m"},
Handle all of the "thumb" target triple architecture variants that llvm handles. llvm-svn: 146746
2011-12-17 02:15:52 +08:00
{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"},
Add recognition of two more armv7 variants, armv7m and armv7em. <rdar://problem/13361372> llvm-svn: 176674
2013-03-08 09:20:17 +08:00
{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"},
Update lldb to track recent Triple arm64 enum removal and collapse into aarch64. See the following llvm change for details: r213743 | tnorthover | 2014-07-23 05:32:47 -0700 (Wed, 23 Jul 2014) | 9 lines AArch64: remove arm64 triple enumerator. This change fixes build breaks on Linux and MacOSX lldb. llvm-svn: 213755
2014-07-23 22:37:35 +08:00
{eByteOrderLittle, 8, 4, 4, llvm::Triple::aarch64,
ArchSpec::eCore_arm_arm64, "arm64"},
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
{eByteOrderLittle, 8, 4, 4, llvm::Triple::aarch64,
ArchSpec::eCore_arm_armv8, "armv8"},
[LLDB] Add core definition for armv8l and armv7l This patch adds core definitions in lldb ArchSpecs for armv8l and armv7l cores. This was needed because on Linux running on 32-bit Arm v8 we are returned armv8l in case we are running 32-bit sysroot on 64bit kernel. In case of 32-bit kernel and 32-bit sysroot running on arm v8 hardware we are returned armv7l. This is quite common when we run 32 bit arm using docker container. Signed-off-by: Muhammad Omair Javaid <omair.javaid@linaro.org> Differential Revision: https://reviews.llvm.org/D69904
2019-11-13 08:30:25 +08:00
{eByteOrderLittle, 4, 2, 4, llvm::Triple::arm,
[LLDB] Add ObjectFileWasm plugin for WebAssembly debugging Summary: This is the first in a series of patches to enable LLDB debugging of WebAssembly targets. Current versions of Clang emit (partial) DWARF debug information in WebAssembly modules and we can leverage this debug information to give LLDB the ability to do source-level debugging of Wasm code that runs in a WebAssembly engine. A way to do this could be to use the remote debugging functionalities provided by LLDB via the GDB-remote protocol. Remote debugging can indeed be useful not only to connect a debugger to a process running on a remote machine, but also to connect the debugger to a managed VM or script engine that runs locally, provided that the engine implements a GDB-remote stub that offers the ability to access the engine runtime internal state. To make this work, the GDB-remote protocol would need to be extended with a few Wasm-specific custom query commands, used to access aspects of the Wasm engine state (like the Wasm memory, Wasm local and global variables, and so on). Furthermore, the DWARF format would need to be enriched with a few Wasm-specific extensions, here detailed: https://yurydelendik.github.io/webassembly-dwarf. This CL introduce classes **ObjectFileWasm**, a file plugin to represent a Wasm module loaded in a debuggee process. It knows how to parse Wasm modules and store the Code section and the DWARF-specific sections. Reviewers: jasonmolenda, clayborg, labath Tags: #lldb Differential Revision: https://reviews.llvm.org/D71575
2020-01-16 07:29:24 +08:00
ArchSpec::eCore_arm_armv8l, "armv8l"},
Add arm64_32 support to lldb, an ILP32 codegen that runs on arm64 ISA targets, specifically Apple watches. Differential Revision: https://reviews.llvm.org/D68858 llvm-svn: 375032
2019-10-17 03:14:49 +08:00
{eByteOrderLittle, 4, 4, 4, llvm::Triple::aarch64_32,
[LLDB] Add ObjectFileWasm plugin for WebAssembly debugging Summary: This is the first in a series of patches to enable LLDB debugging of WebAssembly targets. Current versions of Clang emit (partial) DWARF debug information in WebAssembly modules and we can leverage this debug information to give LLDB the ability to do source-level debugging of Wasm code that runs in a WebAssembly engine. A way to do this could be to use the remote debugging functionalities provided by LLDB via the GDB-remote protocol. Remote debugging can indeed be useful not only to connect a debugger to a process running on a remote machine, but also to connect the debugger to a managed VM or script engine that runs locally, provided that the engine implements a GDB-remote stub that offers the ability to access the engine runtime internal state. To make this work, the GDB-remote protocol would need to be extended with a few Wasm-specific custom query commands, used to access aspects of the Wasm engine state (like the Wasm memory, Wasm local and global variables, and so on). Furthermore, the DWARF format would need to be enriched with a few Wasm-specific extensions, here detailed: https://yurydelendik.github.io/webassembly-dwarf. This CL introduce classes **ObjectFileWasm**, a file plugin to represent a Wasm module loaded in a debuggee process. It knows how to parse Wasm modules and store the Code section and the DWARF-specific sections. Reviewers: jasonmolenda, clayborg, labath Tags: #lldb Differential Revision: https://reviews.llvm.org/D71575
2020-01-16 07:29:24 +08:00
ArchSpec::eCore_arm_arm64_32, "arm64_32"},
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
{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
[LLDB][MIPS] Detect MIPS application specific extensions like micromips SUMMARY: The patch detects MIPS application specific extensions (ASE) like micromips by reading ELF header.e_flags and SHT_MIPS_ABIFLAGS section. MIPS triple does not contain ASE information like micromips, mips16, DSP, MSA etc. These can be read from header.e_flags or SHT_MIPS_ABIFLAGS section. Reviewers: clayborg Subscribers: mohit.bhakkad, sagar, lldb-commits Differential Revision: http://reviews.llvm.org/D11133 llvm-svn: 242381
2015-07-16 11:51:55 +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"},
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
{eByteOrderLittle, 4, 2, 4, llvm::Triple::mipsel, ArchSpec::eCore_mips32el,
"mipsel"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::mipsel,
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
ArchSpec::eCore_mips32r2el, "mipsr2el"},
{eByteOrderLittle, 4, 2, 4, llvm::Triple::mipsel,
Added i686 architecture (ArchSpec::Core::eCore_x86_32_i686). llvm-svn: 205770
2014-04-08 22:48:48 +08:00
ArchSpec::eCore_mips32r3el, "mipsr3el"},
Initial patch for supporting Hexagon DSP llvm-svn: 201665
2014-02-19 19:16:46 +08:00
{eByteOrderLittle, 4, 2, 4, llvm::Triple::mipsel,
ArchSpec::eCore_mips32r5el, "mipsr5el"},
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
{eByteOrderLittle, 4, 2, 4, llvm::Triple::mipsel,
Add support for kalimba architecture variants 3, 4 and 5. Add entries to core_definitions and elf_arch_entries for those variants. Select the subtype for the variant by parsing the e_flags field of the elf header. llvm-svn: 216541
2014-08-27 20:09:39 +08:00
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
[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
// mips64, mips64r2, mips64r3, mips64r5, mips64r6
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
{eByteOrderBig, 8, 2, 4, llvm::Triple::mips64, ArchSpec::eCore_mips64,
[LLDB][MIPS] Detect MIPS application specific extensions like micromips SUMMARY: The patch detects MIPS application specific extensions (ASE) like micromips by reading ELF header.e_flags and SHT_MIPS_ABIFLAGS section. MIPS triple does not contain ASE information like micromips, mips16, DSP, MSA etc. These can be read from header.e_flags or SHT_MIPS_ABIFLAGS section. Reviewers: clayborg Subscribers: mohit.bhakkad, sagar, lldb-commits Differential Revision: http://reviews.llvm.org/D11133 llvm-svn: 242381
2015-07-16 11:51:55 +08:00
"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"},
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
{eByteOrderLittle, 8, 2, 4, llvm::Triple::mips64el,
[LLDB][MIPS] Detect MIPS application specific extensions like micromips SUMMARY: The patch detects MIPS application specific extensions (ASE) like micromips by reading ELF header.e_flags and SHT_MIPS_ABIFLAGS section. MIPS triple does not contain ASE information like micromips, mips16, DSP, MSA etc. These can be read from header.e_flags or SHT_MIPS_ABIFLAGS section. Reviewers: clayborg Subscribers: mohit.bhakkad, sagar, lldb-commits Differential Revision: http://reviews.llvm.org/D11133 llvm-svn: 242381
2015-07-16 11:51:55 +08:00
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,
[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
ArchSpec::eCore_mips64r6el, "mips64r6el"},
*** 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
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
{eByteOrderBig, 4, 4, 4, llvm::Triple::ppc, ArchSpec::eCore_ppc_generic,
First cut of PowerPC(64) support in LLDB. Summary: This adds preliminary support for PowerPC/PowerPC64, for FreeBSD. There are some issues still: * Breakpoints don't work well on powerpc64. * Shared libraries don't yet get loaded for a 32-bit process on powerpc64 host. * Backtraces don't work. This is due to PowerPC ABI using a backchain pointer in memory, instead of a dedicated frame pointer register for the backchain. * Breakpoints on functions without debug info may not work correctly for 32-bit powerpc. Reviewers: emaste, tfiala, jingham, clayborg Reviewed By: clayborg Subscribers: emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D5988 llvm-svn: 220944
2014-10-31 10:34:28 +08:00
"powerpc"},
Change PowerPC to have the correct byte order. llvm-svn: 188189
2013-08-13 02:34:04 +08:00
{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"},
*** 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
Now a ppc64le binary is correctly detected: (lldb) target create "tst" Current executable set to 'tst' (powerpc64le). (lldb) disassemble -n main tst`main: tst[0x7b0] <+0>: addis 2, 12, 2 tst[0x7b4] <+4>: addi 2, 2, 30544 tst[0x7b8] <+8>: mflr 0 Wihout the patch, the endianess was incorrect: (lldb) target create "tst" Current executable set to 'tst' (powerpc64). (lldb) disassemble -n main tst`main: tst[0x7b0] <+0>: .long 0x02004c3c ; unknown opcode tst[0x7b4] <+4>: rlwimi 23, 3, 8, 8, 28 tst[0x7b8] <+8>: lhzu 16, 2172(2) tst[0x7bc] <+12>: .long 0x100001f8 ; unknown opcode Simple binary used is identified as: $ file tst tst: ELF 64-bit LSB shared object, 64-bit PowerPC or cisco 7500, version 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=17a8fa2b24ce2837ba6625fabb34e6b29c6c5db7, not stripped Patch by Gustavo Serra Scalet <gustavo.scalet@eldorado.org.br> Differential Revision: https://reviews.llvm.org/D36804 llvm-svn: 312151
2017-08-31 02:36:48 +08:00
{eByteOrderLittle, 8, 4, 4, llvm::Triple::ppc64le,
Move ArchSpec to the Utility module The rationale here is that ArchSpec is used throughout the codebase, including in places which should not depend on the rest of the code in the Core module. This commit touches many files, but most of it is just renaming of #include lines. In a couple of cases, I removed the #include ArchSpec line altogether, as the file was not using it. In one or two places, this necessitated adding other #includes like lldb-private-defines.h. llvm-svn: 318048
2017-11-14 00:16:33 +08:00
ArchSpec::eCore_ppc64le_generic, "powerpc64le"},
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
{eByteOrderBig, 8, 4, 4, llvm::Triple::ppc64, ArchSpec::eCore_ppc64_generic,
First cut of PowerPC(64) support in LLDB. Summary: This adds preliminary support for PowerPC/PowerPC64, for FreeBSD. There are some issues still: * Breakpoints don't work well on powerpc64. * Shared libraries don't yet get loaded for a 32-bit process on powerpc64 host. * Backtraces don't work. This is due to PowerPC ABI using a backchain pointer in memory, instead of a dedicated frame pointer register for the backchain. * Breakpoints on functions without debug info may not work correctly for 32-bit powerpc. Reviewers: emaste, tfiala, jingham, clayborg Reviewed By: clayborg Subscribers: emaste, lldb-commits Differential Revision: http://reviews.llvm.org/D5988 llvm-svn: 220944
2014-10-31 10:34:28 +08:00
"powerpc64"},
Change PowerPC to have the correct byte order. llvm-svn: 188189
2013-08-13 02:34:04 +08:00
{eByteOrderBig, 8, 4, 4, llvm::Triple::ppc64,
ArchSpec::eCore_ppc64_ppc970_64, "ppc970-64"},
*** 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
Support Linux on SystemZ as platform This patch adds support for Linux on SystemZ: - A new ArchSpec value of eCore_s390x_generic - A new directory Plugins/ABI/SysV-s390x providing an ABI implementation - Register context support - Native Linux support including watchpoint support - ELF core file support - Misc. support throughout the code base (e.g. breakpoint opcodes) - Test case updates to support the platform This should provide complete support for debugging the SystemZ platform. Not yet supported are optional features like transaction support (zEC12) or SIMD vector support (z13). There is no instruction emulation, since our ABI requires that all code provide correct DWARF CFI at all PC locations in .eh_frame to support unwinding (i.e. -fasynchronous-unwind-tables is on by default). The implementation follows existing platforms in a mostly straightforward manner. A couple of things that are different: - We do not use PTRACE_PEEKUSER / PTRACE_POKEUSER to access single registers, since some registers (access register) reside at offsets in the user area that are multiples of 4, but the PTRACE_PEEKUSER interface only allows accessing aligned 8-byte blocks in the user area. Instead, we use a s390 specific ptrace interface PTRACE_PEEKUSR_AREA / PTRACE_POKEUSR_AREA that allows accessing a whole block of the user area in one go, so in effect allowing to treat parts of the user area as register sets. - SystemZ hardware does not provide any means to implement read watchpoints, only write watchpoints. In fact, we can only support a *single* write watchpoint (but this can span a range of arbitrary size). In LLDB this means we support only a single watchpoint. I've set all test cases that require read watchpoints (or multiple watchpoints) to expected failure on the platform. [ Note that there were two test cases that install a read/write watchpoint even though they nowhere rely on the "read" property. I've changed those to simply use plain write watchpoints. ] Differential Revision: http://reviews.llvm.org/D18978 llvm-svn: 266308
2016-04-14 22:28:34 +08:00
{eByteOrderBig, 8, 2, 6, llvm::Triple::systemz,
ArchSpec::eCore_s390x_generic, "s390x"},
*** 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
Initial patch for supporting Hexagon DSP llvm-svn: 201665
2014-02-19 19:16:46 +08:00
{eByteOrderLittle, 4, 4, 4, llvm::Triple::sparc,
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
ArchSpec::eCore_sparc_generic, "sparc"},
Add Kalimba support to ArchSpec. See http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140630/011508.html for more details. Change by Matthew Gardiner. llvm-svn: 212145
2014-07-02 07:33:32 +08:00
{eByteOrderLittle, 8, 4, 4, llvm::Triple::sparcv9,
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
ArchSpec::eCore_sparc9_generic, "sparcv9"},
*** 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
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
{eByteOrderLittle, 4, 1, 15, llvm::Triple::x86, ArchSpec::eCore_x86_32_i386,
*** 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
"i386"},
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
{eByteOrderLittle, 4, 1, 15, llvm::Triple::x86, ArchSpec::eCore_x86_32_i486,
*** 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
"i486"},
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
{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,
*** 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
"i686"},
Add support for Haswell on x86_64. <rdar://problem/15312873> llvm-svn: 199854
2014-01-23 07:42:03 +08:00
{eByteOrderLittle, 8, 1, 15, llvm::Triple::x86_64,
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
ArchSpec::eCore_x86_64_x86_64, "x86_64"},
Add support for Haswell on x86_64. <rdar://problem/15312873> llvm-svn: 199854
2014-01-23 07:42:03 +08:00
{eByteOrderLittle, 8, 1, 15, llvm::Triple::x86_64,
ArchSpec::eCore_x86_64_x86_64h, "x86_64h"},
Initial patch for supporting Hexagon DSP llvm-svn: 201665
2014-02-19 19:16:46 +08:00
{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"},
*** 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
Add Kalimba support to ArchSpec. See http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140630/011508.html for more details. Change by Matthew Gardiner. llvm-svn: 212145
2014-07-02 07:33:32 +08:00
{eByteOrderLittle, 4, 4, 4, llvm::Triple::UnknownArch,
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
ArchSpec::eCore_uknownMach32, "unknown-mach-32"},
Add Kalimba support to ArchSpec. See http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140630/011508.html for more details. Change by Matthew Gardiner. llvm-svn: 212145
2014-07-02 07:33:32 +08:00
{eByteOrderLittle, 8, 4, 4, llvm::Triple::UnknownArch,
ArchSpec::eCore_uknownMach64, "unknown-mach-64"},
[LLDB] Add ObjectFileWasm plugin for WebAssembly debugging Summary: This is the first in a series of patches to enable LLDB debugging of WebAssembly targets. Current versions of Clang emit (partial) DWARF debug information in WebAssembly modules and we can leverage this debug information to give LLDB the ability to do source-level debugging of Wasm code that runs in a WebAssembly engine. A way to do this could be to use the remote debugging functionalities provided by LLDB via the GDB-remote protocol. Remote debugging can indeed be useful not only to connect a debugger to a process running on a remote machine, but also to connect the debugger to a managed VM or script engine that runs locally, provided that the engine implements a GDB-remote stub that offers the ability to access the engine runtime internal state. To make this work, the GDB-remote protocol would need to be extended with a few Wasm-specific custom query commands, used to access aspects of the Wasm engine state (like the Wasm memory, Wasm local and global variables, and so on). Furthermore, the DWARF format would need to be enriched with a few Wasm-specific extensions, here detailed: https://yurydelendik.github.io/webassembly-dwarf. This CL introduce classes **ObjectFileWasm**, a file plugin to represent a Wasm module loaded in a debuggee process. It knows how to parse Wasm modules and store the Code section and the DWARF-specific sections. Reviewers: jasonmolenda, clayborg, labath Tags: #lldb Differential Revision: https://reviews.llvm.org/D71575
2020-01-16 07:29:24 +08:00
{eByteOrderLittle, 4, 2, 4, llvm::Triple::arc, ArchSpec::eCore_arc, "arc"},
{eByteOrderLittle, 4, 1, 4, llvm::Triple::wasm32, ArchSpec::eCore_wasm32,
"wasm32"},
[Platform] Remove Kalimba Platform This patch removes the Kalimba platform. For more information please refer to the corresponding thread on the mailing list. http://lists.llvm.org/pipermail/lldb-dev/2019-March/014921.html llvm-svn: 357086
2019-03-28 00:23: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
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
// Ensure that we have an entry in the g_core_definitions for each core. If you
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// comment out an entry above, you will need to comment out the corresponding
// ArchSpec::Core enumeration.
Fix the MSVC build. MSVC does not support constexpr. llvm-svn: 214091
2014-07-29 00:44:28 +08:00
static_assert(sizeof(g_core_definitions) / sizeof(CoreDefinition) ==
ArchSpec::kNumCores,
"make sure we have one core definition for each core");
*** 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
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
struct ArchDefinitionEntry {
ArchSpec::Core core;
uint32_t cpu;
uint32_t sub;
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
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
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
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
};
Replaced more boilerplate code with CompletionRequest (NFC) Summary: As suggested in D48796, this patch replaces even more internal calls that were using the old completion API style with a single CompletionRequest. In some cases we also pass an option vector/index, but as we don't always have this information, it currently is not part of the CompletionRequest class. The constructor of the CompletionRequest is now also more sensible. You only pass the user input, cursor position and your list of matches to the request and the rest will be inferred (using the same code we used before to calculate this). You also have to pass these match window parameters to it, even though they are unused right now. The patch shouldn't change any behavior. Reviewers: jingham Reviewed By: jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D48976 llvm-svn: 337031
2018-07-14 02:28:14 +08:00
void ArchSpec::ListSupportedArchNames(StringList &list) {
for (uint32_t i = 0; i < llvm::array_lengthof(g_core_definitions); ++i)
list.AppendString(g_core_definitions[i].name);
}
[lldb][NFC] Remove WordComplete mode, make result array indexed from 0 and remove any undocumented/redundant return values Summary: We still have some leftovers of the old completion API in the internals of LLDB that haven't been replaced by the new CompletionRequest. These leftovers are: * The return values (int/size_t) in all completion functions. * Our result array that starts indexing at 1. * `WordComplete` mode. I didn't replace them back then because it's tricky to figure out what exactly they are used for and the completion code is relatively untested. I finally got around to writing more tests for the API and understanding the semantics, so I think it's a good time to get rid of them. A few words why those things should be removed/replaced: * The return values are really cryptic, partly redundant and rarely documented. They are also completely ignored by Xcode, so whatever information they contain will end up breaking Xcode's completion mechanism. They are also partly impossible to even implement as we assign negative values special meaning and our completion API sometimes returns size_t. Completion functions are supposed to return -2 to rewrite the current line. We seem to use this in some untested code path to expand the history repeat character to the full command, but I haven't figured out why that doesn't work at the moment. Completion functions return -1 to 'insert the completion character', but that isn't implemented (even though we seem to activate this feature in LLDB sometimes). All positive values have to match the number of results. This is obviously just redundant information as the user can just look at the result list to get that information (which is what Xcode does). * The result array that starts indexing at 1 is obviously unexpected. The first element of the array is reserved for the common prefix of all completions (e.g. "foobar" and "footar" -> "foo"). The idea is that we calculate this to make the life of the API caller easier, but obviously forcing people to have 1-based indices is not helpful (or even worse, forces them to manually copy the results to make it 0-based like Xcode has to do). * The `WordComplete` mode indicates that LLDB should enter a space behind the completion. The idea is that we let the top-level API know that we just provided a full completion. Interestingly we `WordComplete` is just a single bool that somehow represents all N completions. And we always provide full completions in LLDB, so in theory it should always be true. The only use it currently serves is providing redundant information about whether we have a single definitive completion or not (which we already know from the number of results we get). This patch essentially removes `WordComplete` mode and makes the result array indexed from 0. It also removes all return values from all internal completion functions. The only non-redundant information they contain is about rewriting the current line (which is broken), so that functionality was moved to the CompletionRequest API. So you can now do `addCompletion("blub", "description", CompletionMode::RewriteLine)` to do the same. For the SB API we emulate the old behaviour by making the array indexed from 1 again with the common prefix at index 0. I didn't keep the special negative return codes as we either never sent them before (e.g. -2) or we didn't even implement them in the Editline handler (e.g. -1). I tried to keep this patch minimal and I'm aware we can probably now even further simplify a bunch of related code, but I would prefer doing this in follow-up NFC commits Reviewers: JDevlieghere Reviewed By: JDevlieghere Subscribers: arphaman, abidh, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D66536 llvm-svn: 369624
2019-08-22 15:41:23 +08:00
void ArchSpec::AutoComplete(CompletionRequest &request) {
[lldb][NFC] Remove argument prefix checking boilerplate when adding completions llvm-svn: 372561
2019-09-23 16:59:21 +08:00
for (uint32_t i = 0; i < llvm::array_lengthof(g_core_definitions); ++i)
request.TryCompleteCurrentArg(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
}
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
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 g_macho_arch_entries[] = {
Fix some names in the wake of my Mach-O changes to LLVM. llvm-svn: 189317
2013-08-27 13:04:57 +08:00
{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},
Add entries for arm6m to ArchSpec's g_macho_arch_entries. <rdar://problem/15099306> llvm-svn: 192161
2013-10-08 11:01:08 +08:00
{ArchSpec::eCore_arm_armv6m, llvm::MachO::CPU_TYPE_ARM, 14, UINT32_MAX,
SUBTYPE_MASK},
Fix some names in the wake of my Mach-O changes to LLVM. llvm-svn: 189317
2013-08-27 13:04:57 +08:00
{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},
lldb arm64 import. These changes were written by Greg Clayton, Jim Ingham, Jason Molenda. It builds cleanly against TOT llvm with xcodebuild. I updated the cmake files by visual inspection but did not try a build. I haven't built these sources on any non-Mac platforms - I don't think this patch adds any code that requires darwin, but please let me know if I missed something. In debugserver, MachProcess.cpp and MachTask.cpp were renamed to MachProcess.mm and MachTask.mm as they picked up some new Objective-C code needed to launch processes when running on iOS. llvm-svn: 205113
2014-03-30 02:54:20 +08:00
{ArchSpec::eCore_arm_arm64, llvm::MachO::CPU_TYPE_ARM64, 1, UINT32_MAX,
SUBTYPE_MASK},
Sketch out the armv7 and arm64 core file writing support in ObjectFileMachO. It's close but we seem to be missing some of the memory region segments - not exactly sure how that's happening. The register context writing into the LC_THREAD load commands is working correctly though. Slightly reordered the arm64 definitions in ArchSpec.cpp so when we look for an arm64 core file definiton we're getting a cpu subtype of CPU_ANY which we can't put in the mach header of a core file. Make the first definition we find by linear search have the currently correct '1' cpu subtype. llvm-svn: 221743
2014-11-12 09:11:36 +08:00
{ArchSpec::eCore_arm_arm64, llvm::MachO::CPU_TYPE_ARM64, 0, UINT32_MAX,
SUBTYPE_MASK},
lldb arm64 import. These changes were written by Greg Clayton, Jim Ingham, Jason Molenda. It builds cleanly against TOT llvm with xcodebuild. I updated the cmake files by visual inspection but did not try a build. I haven't built these sources on any non-Mac platforms - I don't think this patch adds any code that requires darwin, but please let me know if I missed something. In debugserver, MachProcess.cpp and MachTask.cpp were renamed to MachProcess.mm and MachTask.mm as they picked up some new Objective-C code needed to launch processes when running on iOS. llvm-svn: 205113
2014-03-30 02:54:20 +08:00
{ArchSpec::eCore_arm_arm64, llvm::MachO::CPU_TYPE_ARM64, 13, UINT32_MAX,
SUBTYPE_MASK},
Add arm64_32 support to lldb, an ILP32 codegen that runs on arm64 ISA targets, specifically Apple watches. Differential Revision: https://reviews.llvm.org/D68858 llvm-svn: 375032
2019-10-17 03:14:49 +08:00
{ArchSpec::eCore_arm_arm64_32, llvm::MachO::CPU_TYPE_ARM64_32, 0,
UINT32_MAX, SUBTYPE_MASK},
{ArchSpec::eCore_arm_arm64_32, llvm::MachO::CPU_TYPE_ARM64_32, 1,
UINT32_MAX, SUBTYPE_MASK},
Sketch out the armv7 and arm64 core file writing support in ObjectFileMachO. It's close but we seem to be missing some of the memory region segments - not exactly sure how that's happening. The register context writing into the LC_THREAD load commands is working correctly though. Slightly reordered the arm64 definitions in ArchSpec.cpp so when we look for an arm64 core file definiton we're getting a cpu subtype of CPU_ANY which we can't put in the mach header of a core file. Make the first definition we find by linear search have the currently correct '1' cpu subtype. llvm-svn: 221743
2014-11-12 09:11:36 +08:00
{ArchSpec::eCore_arm_arm64, llvm::MachO::CPU_TYPE_ARM64, CPU_ANY,
UINT32_MAX, SUBTYPE_MASK},
Fix some names in the wake of my Mach-O changes to LLVM. llvm-svn: 189317
2013-08-27 13:04:57 +08:00
{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},
Add entries for arm6m to ArchSpec's g_macho_arch_entries. <rdar://problem/15099306> llvm-svn: 192161
2013-10-08 11:01:08 +08:00
{ArchSpec::eCore_thumbv6m, llvm::MachO::CPU_TYPE_ARM, 14, UINT32_MAX,
SUBTYPE_MASK},
Fix some names in the wake of my Mach-O changes to LLVM. llvm-svn: 189317
2013-08-27 13:04:57 +08:00
{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},
Add float/vector registers for ppc64le Summary: Add read and write functions for VSX, VMX and float registers and fix watchpoint size Reviewers: clayborg Reviewed By: clayborg Subscribers: eugene, labath, clayborg, nemanjai, kbarton, JDevlieghere, anajuliapc, gut, lbianc, lldb-commits Differential Revision: https://reviews.llvm.org/D39487 Patch by: Alexandre Yukio Yamashita <alexandre.yamashita@eldorado.org.br> llvm-svn: 317329
2017-11-03 23:22:36 +08:00
{ArchSpec::eCore_ppc64le_generic, llvm::MachO::CPU_TYPE_POWERPC64, CPU_ANY,
UINT32_MAX, SUBTYPE_MASK},
Fix some names in the wake of my Mach-O changes to LLVM. llvm-svn: 189317
2013-08-27 13:04:57 +08:00
{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,
Add support for Haswell on x86_64. <rdar://problem/15312873> llvm-svn: 199854
2014-01-23 07:42:03 +08:00
UINT32_MAX, SUBTYPE_MASK},
{ArchSpec::eCore_x86_32_i386, llvm::MachO::CPU_TYPE_I386, CPU_ANY,
UINT32_MAX, UINT32_MAX},
Fix some names in the wake of my Mach-O changes to LLVM. llvm-svn: 189317
2013-08-27 13:04:57 +08:00
{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,
Add support for Haswell on x86_64. <rdar://problem/15312873> llvm-svn: 199854
2014-01-23 07:42:03 +08:00
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},
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
// Catch any unknown mach architectures so we can always use the object and
// symbol mach-o files
Fix some names in the wake of my Mach-O changes to LLVM. llvm-svn: 189317
2013-08-27 13:04:57 +08:00
{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 = {
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
eArchTypeMachO, llvm::array_lengthof(g_macho_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
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.
static const ArchDefinitionEntry g_elf_arch_entries[] = {
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
{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
Fix the lldb build for the EM_486 change. llvm-svn: 240138
2015-06-20 01:02:25 +08:00
{ArchSpec::eCore_x86_32_i486, llvm::ELF::EM_IAMCU, LLDB_INVALID_CPUTYPE,
0xFFFFFFFFu, 0xFFFFFFFFu}, // Intel MCU // FIXME: is this correct?
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
{ArchSpec::eCore_ppc_generic, llvm::ELF::EM_PPC, LLDB_INVALID_CPUTYPE,
0xFFFFFFFFu, 0xFFFFFFFFu}, // PowerPC
Now a ppc64le binary is correctly detected: (lldb) target create "tst" Current executable set to 'tst' (powerpc64le). (lldb) disassemble -n main tst`main: tst[0x7b0] <+0>: addis 2, 12, 2 tst[0x7b4] <+4>: addi 2, 2, 30544 tst[0x7b8] <+8>: mflr 0 Wihout the patch, the endianess was incorrect: (lldb) target create "tst" Current executable set to 'tst' (powerpc64). (lldb) disassemble -n main tst`main: tst[0x7b0] <+0>: .long 0x02004c3c ; unknown opcode tst[0x7b4] <+4>: rlwimi 23, 3, 8, 8, 28 tst[0x7b8] <+8>: lhzu 16, 2172(2) tst[0x7bc] <+12>: .long 0x100001f8 ; unknown opcode Simple binary used is identified as: $ file tst tst: ELF 64-bit LSB shared object, 64-bit PowerPC or cisco 7500, version 1 (SYSV), dynamically linked, interpreter /lib64/ld64.so.2, for GNU/Linux 3.2.0, BuildID[sha1]=17a8fa2b24ce2837ba6625fabb34e6b29c6c5db7, not stripped Patch by Gustavo Serra Scalet <gustavo.scalet@eldorado.org.br> Differential Revision: https://reviews.llvm.org/D36804 llvm-svn: 312151
2017-08-31 02:36:48 +08:00
{ArchSpec::eCore_ppc64le_generic, llvm::ELF::EM_PPC64, LLDB_INVALID_CPUTYPE,
0xFFFFFFFFu, 0xFFFFFFFFu}, // PowerPC64le
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
{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
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
{ArchSpec::eCore_arm_aarch64, llvm::ELF::EM_AARCH64, LLDB_INVALID_CPUTYPE,
0xFFFFFFFFu, 0xFFFFFFFFu}, // ARM64
Support Linux on SystemZ as platform This patch adds support for Linux on SystemZ: - A new ArchSpec value of eCore_s390x_generic - A new directory Plugins/ABI/SysV-s390x providing an ABI implementation - Register context support - Native Linux support including watchpoint support - ELF core file support - Misc. support throughout the code base (e.g. breakpoint opcodes) - Test case updates to support the platform This should provide complete support for debugging the SystemZ platform. Not yet supported are optional features like transaction support (zEC12) or SIMD vector support (z13). There is no instruction emulation, since our ABI requires that all code provide correct DWARF CFI at all PC locations in .eh_frame to support unwinding (i.e. -fasynchronous-unwind-tables is on by default). The implementation follows existing platforms in a mostly straightforward manner. A couple of things that are different: - We do not use PTRACE_PEEKUSER / PTRACE_POKEUSER to access single registers, since some registers (access register) reside at offsets in the user area that are multiples of 4, but the PTRACE_PEEKUSER interface only allows accessing aligned 8-byte blocks in the user area. Instead, we use a s390 specific ptrace interface PTRACE_PEEKUSR_AREA / PTRACE_POKEUSR_AREA that allows accessing a whole block of the user area in one go, so in effect allowing to treat parts of the user area as register sets. - SystemZ hardware does not provide any means to implement read watchpoints, only write watchpoints. In fact, we can only support a *single* write watchpoint (but this can span a range of arbitrary size). In LLDB this means we support only a single watchpoint. I've set all test cases that require read watchpoints (or multiple watchpoints) to expected failure on the platform. [ Note that there were two test cases that install a read/write watchpoint even though they nowhere rely on the "read" property. I've changed those to simply use plain write watchpoints. ] Differential Revision: http://reviews.llvm.org/D18978 llvm-svn: 266308
2016-04-14 22:28:34 +08:00
{ArchSpec::eCore_s390x_generic, llvm::ELF::EM_S390, LLDB_INVALID_CPUTYPE,
0xFFFFFFFFu, 0xFFFFFFFFu}, // SystemZ
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
{ArchSpec::eCore_sparc9_generic, llvm::ELF::EM_SPARCV9,
LLDB_INVALID_CPUTYPE, 0xFFFFFFFFu, 0xFFFFFFFFu}, // SPARC V9
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
{ArchSpec::eCore_x86_64_x86_64, llvm::ELF::EM_X86_64, LLDB_INVALID_CPUTYPE,
0xFFFFFFFFu, 0xFFFFFFFFu}, // AMD64
[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
{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
Add Kalimba support to ArchSpec. See http://lists.cs.uiuc.edu/pipermail/lldb-commits/Week-of-Mon-20140630/011508.html for more details. Change by Matthew Gardiner. llvm-svn: 212145
2014-07-02 07:33:32 +08:00
{ArchSpec::eCore_hexagon_generic, llvm::ELF::EM_HEXAGON,
LLDB_INVALID_CPUTYPE, 0xFFFFFFFFu, 0xFFFFFFFFu}, // HEXAGON
[ARC] Basic support in gdb-remote process plugin Differential Revision: https://reviews.llvm.org/D55718 llvm-svn: 375122
2019-10-17 23:16:21 +08:00
{ArchSpec::eCore_arc, llvm::ELF::EM_ARC_COMPACT2, LLDB_INVALID_CPUTYPE,
[lldb][NFC] Make clang-format happy by removing trailing space in ArchSpec.cpp
2019-12-17 16:13:23 +08:00
0xFFFFFFFFu, 0xFFFFFFFFu}, // ARC
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 = {
Move ArchSpec to the Utility module The rationale here is that ArchSpec is used throughout the codebase, including in places which should not depend on the rest of the code in the Core module. This commit touches many files, but most of it is just renaming of #include lines. In a couple of cases, I removed the #include ArchSpec line altogether, as the file was not using it. In one or two places, this necessitated adding other #includes like lldb-private-defines.h. llvm-svn: 318048
2017-11-14 00:16:33 +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
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 ArchDefinitionEntry g_coff_arch_entries[] = {
Fix supported architectures on PlatformWindows. i386, i486, i486sx, and i686 are all indistinguishable as far as PE/COFF files are concerned. This patch adds support for all of these architectures to PlatformWindows. Differential Revision: http://reviews.llvm.org/D4658 llvm-svn: 214092
2014-07-29 00:44:49 +08:00
{ArchSpec::eCore_x86_32_i386, llvm::COFF::IMAGE_FILE_MACHINE_I386,
LLDB_INVALID_CPUTYPE, 0xFFFFFFFFu, 0xFFFFFFFFu}, // Intel 80x86
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
{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
update for renaming in LLVM llvm-svn: 203533
2014-03-11 11:09:08 +08:00
{ArchSpec::eCore_arm_armv7, llvm::COFF::IMAGE_FILE_MACHINE_ARMNT,
LLDB_INVALID_CPUTYPE, 0xFFFFFFFFu, 0xFFFFFFFFu}, // ARMv7
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
{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] Add tests for PECOFF arm architecture identification Add a test case for the change from SVN r372657, and for the preexisting ARM identification. Add a missing ArchDefinitionEntry for PECOFF/arm64, and tweak the ArmNt case to set the architecture to armv7 (ArmNt never ran on anything lower than that). (This avoids a case where ArchSpec::MergeFrom would override the arch from arm to armv7 and ArchSpec::CoreUpdated would reset the OS to unknown at the same time.) Differential Revision: https://reviews.llvm.org/D67951 llvm-svn: 372741
2019-09-24 20:20:52 +08:00
LLDB_INVALID_CPUTYPE, 0xFFFFFFFFu, 0xFFFFFFFFu}, // AMD64
{ArchSpec::eCore_arm_arm64, llvm::COFF::IMAGE_FILE_MACHINE_ARM64,
LLDB_INVALID_CPUTYPE, 0xFFFFFFFFu, 0xFFFFFFFFu} // ARM64
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 = {
Move ArchSpec to the Utility module The rationale here is that ArchSpec is used throughout the codebase, including in places which should not depend on the rest of the code in the Core module. This commit touches many files, but most of it is just renaming of #include lines. In a couple of cases, I removed the #include ArchSpec line altogether, as the file was not using it. In one or two places, this necessitated adding other #includes like lldb-private-defines.h. llvm-svn: 318048
2017-11-14 00:16:33 +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[] = {
&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
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
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.
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;
}
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;
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.
static const CoreDefinition *FindCoreDefinition(llvm::StringRef name) {
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
for (unsigned int i = 0; i < llvm::array_lengthof(g_core_definitions); ++i) {
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
if (name.equals_lower(g_core_definitions[i].name))
return &g_core_definitions[i];
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
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 inline const CoreDefinition *FindCoreDefinition(ArchSpec::Core core) {
[Core] Comparison for unsigned >= 0 is redundant. NFCI. llvm-svn: 317145
2017-11-02 07:49:23 +08:00
if (core < llvm::array_lengthof(g_core_definitions))
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
return &g_core_definitions[core];
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;
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 *
FindArchDefinitionEntry(const ArchDefinition *def, uint32_t cpu, uint32_t sub) {
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 (def == nullptr)
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
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
const ArchDefinitionEntry *entries = def->entries;
for (size_t i = 0; i < def->num_entries; ++i) {
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
if (entries[i].cpu == (cpu & entries[i].cpu_mask))
if (entries[i].sub == (sub & entries[i].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
return &entries[i];
*** 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
}
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;
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 *
FindArchDefinitionEntry(const ArchDefinition *def, ArchSpec::Core core) {
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 (def == nullptr)
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
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
const ArchDefinitionEntry *entries = def->entries;
for (size_t i = 0; i < def->num_entries; ++i) {
if (entries[i].core == core)
return &entries[i];
*** 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
}
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;
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) {
<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
if (triple_cstr)
SetTriple(triple_cstr);
}
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) {
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
SetArchitecture(arch_type, cpu, subtype);
}
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
void ArchSpec::Clear() {
m_triple = llvm::Triple();
m_core = kCore_invalid;
m_byte_order = eByteOrderInvalid;
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
m_distribution_id.Clear();
[LLDB][MIPS] Detect MIPS application specific extensions like micromips SUMMARY: The patch detects MIPS application specific extensions (ASE) like micromips by reading ELF header.e_flags and SHT_MIPS_ABIFLAGS section. MIPS triple does not contain ASE information like micromips, mips16, DSP, MSA etc. These can be read from header.e_flags or SHT_MIPS_ABIFLAGS section. Reviewers: clayborg Subscribers: mohit.bhakkad, sagar, lldb-commits Differential Revision: http://reviews.llvm.org/D11133 llvm-svn: 242381
2015-07-16 11:51:55 +08:00
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
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
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
}
Simplify ArchSpec::IsMIPS() llvm-svn: 360865
2019-05-16 16:37:32 +08:00
bool ArchSpec::IsMIPS() const { return GetTriple().isMIPS(); }
[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);
}
Made GetClangTargetCPU() const. Summary: It does not change members or call non-const members. HostInfo::GetArchitecture() returns a const object ref (maybe others?), which can't access the non-const function. Reviewers: labath, eugene Reviewed By: labath, eugene Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D30515 Author: Jason Majors <jmajors@google.com> llvm-svn: 296868
2017-03-03 21:35:49 +08:00
std::string ArchSpec::GetClangTargetCPU() const {
[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
std::string cpu;
*** 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
Simplify ArchSpec::IsMIPS() llvm-svn: 360865
2019-05-16 16:37:32 +08:00
if (IsMIPS()) {
[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
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;
}
*** 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][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
return cpu;
}
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
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
}
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
return LLDB_INVALID_CPUTYPE;
}
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
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) {
Did a lot more work on abtracting and organizing the platforms. On Mac OS X we now have 3 platforms: PlatformDarwin - must be subclassed to fill in the missing pure virtual funcs but this implements all the common functionality between remote-macosx and remote-ios. It also allows for another platform to be used (remote-gdb-server for now) when doing remote connections. Keeping this pluggable will allow for flexibility. PlatformMacOSX - Now implements both local and remote macosx desktop platforms. PlatformRemoteiOS - Remote only iOS that knows how to locate SDK files in the cached SDK locations on the host. A new agnostic platform has been created: PlatformRemoteGDBServer - this implements the platform using the GDB remote protocol and uses the built in lldb_private::Host static functions to implement many queries. llvm-svn: 128193
2011-03-24 12:28:38 +08:00
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
}
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
return LLDB_INVALID_CPUTYPE;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
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
uint32_t ArchSpec::GetDataByteSize() const {
return 1;
}
uint32_t ArchSpec::GetCodeByteSize() const {
return 1;
}
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
llvm::Triple::ArchType ArchSpec::GetMachine() const {
const CoreDefinition *core_def = FindCoreDefinition(m_core);
if (core_def)
return core_def->machine;
return llvm::Triple::UnknownArch;
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
}
Pass ConstString by value (NFC) My apologies for the large patch. With the exception of ConstString.h itself it was entirely produced by sed. ConstString has exactly one const char * data member, so passing a ConstString by reference is not any more efficient than copying it by value. In both cases a single pointer is passed. But passing it by value makes it harder to accidentally return the address of a local object. (This fixes rdar://problem/48640859 for the Apple folks) Differential Revision: https://reviews.llvm.org/D59030 llvm-svn: 355553
2019-03-07 05:22:25 +08:00
ConstString ArchSpec::GetDistributionId() const {
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
return m_distribution_id;
}
void ArchSpec::SetDistributionId(const char *distribution_id) {
m_distribution_id.SetCString(distribution_id);
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
uint32_t ArchSpec::GetAddressByteSize() const {
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
const CoreDefinition *core_def = FindCoreDefinition(m_core);
if (core_def) {
[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
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;
}
return core_def->addr_byte_size;
*** 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
}
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
return 0;
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
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
}
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
bool ArchSpec::CharIsSignedByDefault() const {
switch (m_triple.getArch()) {
default:
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
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
case llvm::Triple::aarch64:
Add arm64_32 support to lldb, an ILP32 codegen that runs on arm64 ISA targets, specifically Apple watches. Differential Revision: https://reviews.llvm.org/D68858 llvm-svn: 375032
2019-10-17 03:14:49 +08:00
case llvm::Triple::aarch64_32:
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
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();
*** 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
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
case llvm::Triple::ppc:
case llvm::Triple::ppc64:
return m_triple.isOSDarwin();
*** 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
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
case llvm::Triple::ppc64le:
case llvm::Triple::systemz:
case llvm::Triple::xcore:
[ARC] Make char unsigned by default Summary: This patch specifies 'char' default sign on ARC. Reviewers: tatyana-krasnukha, clayborg Reviewed By: tatyana-krasnukha, clayborg Subscribers: clayborg, lldb-commits Differential Revision: https://reviews.llvm.org/D51594 llvm-svn: 341667
2018-09-07 22:45:32 +08:00
case llvm::Triple::arc:
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
return false;
}
}
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
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.
bool ArchSpec::SetTriple(const llvm::Triple &triple) {
m_triple = triple;
Recompute ArchSpec core after MergeFrom Summary: MergeFrom was updating the architecture if the target triple did not have it set. However, it was leaving the core field as invalid. This resulted in assertion failures in core file tests as a missing core meant we were unable to compute the address byte size properly. Add a unit test for the new behaviour. Reviewers: jingham, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D32221 llvm-svn: 300836
2017-04-20 20:30:18 +08:00
UpdateCore();
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
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) {
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
// 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
Allow ArchSpec to take a StringRef. llvm-svn: 281662
2016-09-16 05:32:57 +08:00
bool ArchSpec::SetTriple(llvm::StringRef triple) {
if (triple.empty()) {
<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
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;
Remove last Host usage from ArchSpec Summary: In D39387, I was quick to jump to conclusion that ArchSpec has no external dependencies. It turns there still was one call to HostInfo::GetArchitecture left -- for implementing the "systemArch32" architecture and friends. Since GetAugmentedArchSpec is the place we handle these "incomplete" triples that don't specify os or vendor and "systemArch" looks very much like an incomplete triple, I move its handling there. After this ArchSpec *really* does not have external dependencies, and I'll move it to the Utility module as a follow-up. Reviewers: zturner, clayborg, jingham Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D39896 llvm-svn: 318046
2017-11-13 23:57:20 +08:00
SetTriple(llvm::Triple(llvm::Triple::normalize(triple)));
<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 IsValid();
}
Invert ArchSpec<->Platform dependency Summary: ArchSpec::SetTriple was taking a Platform as an argument, and used it to fill in missing pieces of the specified triple. I invert the dependency by moving this code to other classes. For this purpose, I've created three new functions. - HostInfo::GetAugmentedArchSpec: fills in the triple using the host platform (this used to be implemented by passing a null platform pointer). By putting this code in the Host module, we can provide a way to anyone who does not have a platform instance (lldb-server) an easy way to get Host data. - Platform::GetAugmentedArchSpec: if you have a platform instance, you can call this to let it fill in the triple. - static Platform::GetAugmentedArchSpec: implements the "if platform == 0 then use_host() else use_platform()" part. Reviewers: zturner, jingham, clayborg Subscribers: mgorny, javed.absar, lldb-commits Differential Revision: https://reviews.llvm.org/D39387 llvm-svn: 316987
2017-10-31 18:56:03 +08:00
bool ArchSpec::ContainsOnlyArch(const llvm::Triple &normalized_triple) {
return !normalized_triple.getArchName().empty() &&
normalized_triple.getOSName().empty() &&
normalized_triple.getVendorName().empty() &&
normalized_triple.getEnvironmentName().empty();
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
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
void ArchSpec::MergeFrom(const ArchSpec &other) {
[Utility] Remove Triple{Environment,OS,Vendor}IsUnspecifiedUnknown from ArchSpec Summary: These functions should always return the opposite of the `Triple{Environment,OS,Vendor}WasSpecified` functions. Unspecified unknown is the same as unspecified, which is why one set of functions should give us what we want. It's possible to have specified unknown, which is why we can't just rely on checking the enum values of vendor/os/environment. We must also ensure that the names of these are empty and not "unknown". Differential Revision: https://reviews.llvm.org/D58653 llvm-svn: 354933
2019-02-27 07:50:19 +08:00
if (!TripleVendorWasSpecified() && other.TripleVendorWasSpecified())
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
GetTriple().setVendor(other.GetTriple().getVendor());
Fix bug in ArchSpec::MergeFrom Previous ArchSpec tests didn't catch this bug since we never tested just the OS being out of date. Fixed the bug and covered this with a test that would catch this. This was found when trying to load a core file where the core file was an ELF file with just the e_machine for architeture and where the ELF header had no OS set in the OSABI field of the e_ident. It wasn't merging the architecture with the target architecture correctly. Differential Revision: https://reviews.llvm.org/D61659 llvm-svn: 360292
2019-05-09 06:03:22 +08:00
if (!TripleOSWasSpecified() && other.TripleOSWasSpecified())
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
GetTriple().setOS(other.GetTriple().getOS());
Recompute ArchSpec core after MergeFrom Summary: MergeFrom was updating the architecture if the target triple did not have it set. However, it was leaving the core field as invalid. This resulted in assertion failures in core file tests as a missing core meant we were unable to compute the address byte size properly. Add a unit test for the new behaviour. Reviewers: jingham, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D32221 llvm-svn: 300836
2017-04-20 20:30:18 +08:00
if (GetTriple().getArch() == llvm::Triple::UnknownArch) {
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
GetTriple().setArch(other.GetTriple().getArch());
[ArchSpec] Don't consider Unknown MachO64 as invalid. Even without a proper arch we can access line tables, etc.. <rdar://problem/35778442> llvm-svn: 321856
2018-01-05 10:50:24 +08:00
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// MachO unknown64 isn't really invalid as the debugger can still obtain
// information from the binary, e.g. line tables. As such, we don't update
// the core here.
[ArchSpec] Don't consider Unknown MachO64 as invalid. Even without a proper arch we can access line tables, etc.. <rdar://problem/35778442> llvm-svn: 321856
2018-01-05 10:50:24 +08:00
if (other.GetCore() != eCore_uknownMach64)
UpdateCore();
Recompute ArchSpec core after MergeFrom Summary: MergeFrom was updating the architecture if the target triple did not have it set. However, it was leaving the core field as invalid. This resulted in assertion failures in core file tests as a missing core meant we were unable to compute the address byte size properly. Add a unit test for the new behaviour. Reviewers: jingham, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D32221 llvm-svn: 300836
2017-04-20 20:30:18 +08:00
}
[Utility] Remove Triple{Environment,OS,Vendor}IsUnspecifiedUnknown from ArchSpec Summary: These functions should always return the opposite of the `Triple{Environment,OS,Vendor}WasSpecified` functions. Unspecified unknown is the same as unspecified, which is why one set of functions should give us what we want. It's possible to have specified unknown, which is why we can't just rely on checking the enum values of vendor/os/environment. We must also ensure that the names of these are empty and not "unknown". Differential Revision: https://reviews.llvm.org/D58653 llvm-svn: 354933
2019-02-27 07:50:19 +08:00
if (!TripleEnvironmentWasSpecified() &&
[Utility] Fix ArchSpec.MergeFrom to correctly merge environments Summary: This behavior was originally added in rL252264 (git commit 76a7f365da) in order to be extra careful with handling platforms like watchos and tvos. However, as far as triples go, those two (and others) are treated as OSes and not environments, so that should not really apply here. Additionally, this behavior is incorrect and can lead to incorrect ArchSpecs. Because android is specified as an environment and not an OS, not propogating the environment can lead to modules and targets being misidentified. Differential Revision: https://reviews.llvm.org/D58664 llvm-svn: 354938
2019-02-27 08:47:39 +08:00
other.TripleEnvironmentWasSpecified()) {
GetTriple().setEnvironment(other.GetTriple().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
}
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
// If this and other are both arm ArchSpecs and this ArchSpec is a generic
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// "some kind of arm" spec but the other ArchSpec is a specific arm core,
// adopt the specific arm core.
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
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();
Avoid triple corruption while merging core info Summary: This patch fixes a bug where when target triple created from elf information is arm-*-linux-eabihf and platform triple is armv8l-*-linux-gnueabihf. Merging both triple results in armv8l--unknown-unknown. This happens because we order a triple update while calling CoreUpdated and CoreUpdated creates a new triple with no vendor or environment information. Making sure we do not update triple and just update to more specific core fixes the issue. Reviewers: labath, jasonmolenda, clayborg Reviewed By: jasonmolenda Subscribers: jankratochvil, kristof.beyls, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70155
2019-12-05 16:04:04 +08:00
CoreUpdated(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
}
Improve the posix core file triple detection Summary: Posix core files sometime don't contain enough information to correctly detect the OS. If that is the case we should use the OS from the target instead as it will contain usable information in more cases and if the target and the core contain different OS-es then we are already in a pretty bad state so moving from an unknown OS to a known (but possibly incorrect) OS will do no harm. We already had similar code in place for MIPS. This change tries to make it more generic by using ArchSpec::MergeFrom and extends it to all architectures but some MIPS specific issue prevent us from getting rid of special casing MIPS. Reviewers: clayborg, nitesh.jain Subscribers: aemerson, sdardis, arichardson, kristof.beyls, lldb-commits Differential Revision: https://reviews.llvm.org/D36046 llvm-svn: 317411
2017-11-05 02:25:51 +08:00
if (GetFlags() == 0) {
SetFlags(other.GetFlags());
}
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
}
Improve OSType initialization in elf object file's arch_spec Setting the OSType in the ArchSpec triple is needed to correctly setup up the register context plugin. ArchSpec::SetArchitecture, for Mach-O only, sets the OSType. For ELF it was left to the ObjectFileELF to fill in the missing OSType. This change moves the ObjectFileELF logic into ArchSpec. A new optional 'os' parameter has been added to SetArchitecture. For ELF, this value is the from the ELF header.e_ident[EI_OSABI]. The default value is 0 or ELFOSABI_NONE. The real work of determining the OSType was done by the ObjectFileELF helper function GetOsFromOSABI. This logic has been moved SetArchitecture. GetOsFromOSABI has been commented as being deprectated. It is left in to support asserts. For ELF the vendor value returned from SetArchitecture should be UnknownVendor. An unneeded resetting in ObjectFileELF has been removed and replaced with an assert. This fixes a problem reading a core file on FreeBSD/ARM because the spec triple was arm-unknown-unknown. Patch by Tom Rix. Differential Revision: http://reviews.llvm.org/D9292 llvm-svn: 239148
2015-06-05 21:03:08 +08:00
bool ArchSpec::SetArchitecture(ArchitectureType arch_type, uint32_t cpu,
uint32_t sub, uint32_t os) {
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
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;
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// Always use the architecture name because it might be more
// descriptive than the architecture enum ("armv7" ->
// llvm::Triple::arm).
The first part of a fix for being able to select an architecture slice from a file when the target has a triple with an unknown vendor and/or OS and the slice of the file itself has a valid vendor and/or OS. The Module now adopts the ObjectFile's architecture after a valid architecture has been loaded to make sure the module matches the object file. llvm-svn: 140236
2011-09-21 11:57:31 +08:00
m_triple.setArchName(llvm::StringRef(core_def->name));
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
if (arch_type == eArchTypeMachO) {
m_triple.setVendor(llvm::Triple::Apple);
*** 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
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
// Don't set the OS. It could be simulator, macosx, ios, watchos,
[Platform] Remove Kalimba Platform This patch removes the Kalimba platform. For more information please refer to the corresponding thread on the mailing list. http://lists.llvm.org/pipermail/lldb-dev/2019-March/014921.html llvm-svn: 357086
2019-03-28 00:23:50 +08:00
// tvos, bridgeos. 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.
Improve OSType initialization in elf object file's arch_spec Setting the OSType in the ArchSpec triple is needed to correctly setup up the register context plugin. ArchSpec::SetArchitecture, for Mach-O only, sets the OSType. For ELF it was left to the ObjectFileELF to fill in the missing OSType. This change moves the ObjectFileELF logic into ArchSpec. A new optional 'os' parameter has been added to SetArchitecture. For ELF, this value is the from the ELF header.e_ident[EI_OSABI]. The default value is 0 or ELFOSABI_NONE. The real work of determining the OSType was done by the ObjectFileELF helper function GetOsFromOSABI. This logic has been moved SetArchitecture. GetOsFromOSABI has been commented as being deprectated. It is left in to support asserts. For ELF the vendor value returned from SetArchitecture should be UnknownVendor. An unneeded resetting in ObjectFileELF has been removed and replaced with an assert. This fixes a problem reading a core file on FreeBSD/ARM because the spec triple was arm-unknown-unknown. Patch by Tom Rix. Differential Revision: http://reviews.llvm.org/D9292 llvm-svn: 239148
2015-06-05 21:03:08 +08:00
} else if (arch_type == eArchTypeELF) {
switch (os) {
Leave OS as unspecified unknown if it isn't specified in the ELF file This is the redone of r238623 what was reverted with the refactor in r239148. Differential revision: http://reviews.llvm.org/D10957 llvm-svn: 241569
2015-07-07 17:11:59 +08:00
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);
*** 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;
Improve OSType initialization in elf object file's arch_spec Setting the OSType in the ArchSpec triple is needed to correctly setup up the register context plugin. ArchSpec::SetArchitecture, for Mach-O only, sets the OSType. For ELF it was left to the ObjectFileELF to fill in the missing OSType. This change moves the ObjectFileELF logic into ArchSpec. A new optional 'os' parameter has been added to SetArchitecture. For ELF, this value is the from the ELF header.e_ident[EI_OSABI]. The default value is 0 or ELFOSABI_NONE. The real work of determining the OSType was done by the ObjectFileELF helper function GetOsFromOSABI. This logic has been moved SetArchitecture. GetOsFromOSABI has been commented as being deprectated. It is left in to support asserts. For ELF the vendor value returned from SetArchitecture should be UnknownVendor. An unneeded resetting in ObjectFileELF has been removed and replaced with an assert. This fixes a problem reading a core file on FreeBSD/ARM because the spec triple was arm-unknown-unknown. Patch by Tom Rix. Differential Revision: http://reviews.llvm.org/D9292 llvm-svn: 239148
2015-06-05 21:03:08 +08:00
}
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);
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
} 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
}
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// Fall back onto setting the machine type if the arch by name
// failed...
The first part of a fix for being able to select an architecture slice from a file when the target has a triple with an unknown vendor and/or OS and the slice of the file itself has a valid vendor and/or OS. The Module now adopts the ObjectFile's architecture after a valid architecture has been loaded to make sure the module matches the object file. llvm-svn: 140236
2011-09-21 11:57:31 +08:00
if (m_triple.getArch() == llvm::Triple::UnknownArch)
m_triple.setArch(core_def->machine);
*** 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
}
Add logging when ArchSpec::SetArchitecture is given a cputype and cpusubtype that don't map to any known core definition. <rdar://problem/39779398> llvm-svn: 331236
2018-05-01 08:05:54 +08:00
} else {
Log to the process channel, not target twice. llvm-svn: 331239
2018-05-01 08:42:17 +08:00
Log *log(lldb_private::GetLogIfAnyCategoriesSet(LIBLLDB_LOG_TARGET | LIBLLDB_LOG_PROCESS | LIBLLDB_LOG_PLATFORM));
[Logging] Replace Log::Printf with LLDB_LOG macro (NFC) This patch replaces explicit calls to log::Printf with the new LLDB_LOGF macro. The macro is similar to LLDB_LOG but supports printf-style format strings, instead of formatv-style format strings. So instead of writing: if (log) log->Printf("%s\n", str); You'd write: LLDB_LOG(log, "%s\n", str); This change was done mechanically with the command below. I replaced the spurious if-checks with vim, since I know how to do multi-line replacements with it. find . -type f -name '*.cpp' -exec \ sed -i '' -E 's/log->Printf\(/LLDB_LOGF\(log, /g' "{}" + Differential revision: https://reviews.llvm.org/D65128 llvm-svn: 366936
2019-07-25 01:56:10 +08:00
LLDB_LOGF(log,
"Unable to find a core definition for cpu 0x%" PRIx32
" sub %" PRId32,
cpu, 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
}
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
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
}
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
uint32_t ArchSpec::GetMinimumOpcodeByteSize() const {
const CoreDefinition *core_def = FindCoreDefinition(m_core);
if (core_def)
return core_def->min_opcode_byte_size;
return 0;
}
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
}
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
bool ArchSpec::IsExactMatch(const ArchSpec &rhs) const {
Removed the == and != operators from ArchSpec, since equality can be strict or loose and we want code to explicitly choose one or the other. Also renamed the Compare function to IsEqualTo, to avoid confusion. <rdar://problem/12856749> llvm-svn: 170152
2012-12-14 06:07:14 +08:00
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
}
bool ArchSpec::IsCompatibleMatch(const ArchSpec &rhs) const {
Removed the == and != operators from ArchSpec, since equality can be strict or loose and we want code to explicitly choose one or the other. Also renamed the Compare function to IsEqualTo, to avoid confusion. <rdar://problem/12856749> llvm-svn: 170152
2012-12-14 06:07:14 +08:00
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
}
Add a unit test for ArchSpec matching to document how it behaves (and test it). llvm-svn: 348440
2018-12-06 08:43:55 +08:00
static bool IsCompatibleEnvironment(llvm::Triple::EnvironmentType lhs,
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
llvm::Triple::EnvironmentType rhs) {
if (lhs == rhs)
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
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
// If any of the environment is unknown then they are compatible
if (lhs == llvm::Triple::UnknownEnvironment ||
rhs == llvm::Triple::UnknownEnvironment)
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
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
// If one of the environment is Android and the other one is EABI then they
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// 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.
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
if ((lhs == llvm::Triple::Android && rhs == llvm::Triple::EABI) ||
Fix arm-linux-gnueabi regression due to rL267291 rL267291 introduces a lot regression on arm-linux LLDB testsuite. This patch fixes half of them. I am merging it under already revied android counterpart. Another patch fixing rest of the issue will follow this commit. Differential revision: http://reviews.llvm.org/D19480 llvm-svn: 267508
2016-04-26 09:08:59 +08:00
(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))
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 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
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
}
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
bool ArchSpec::IsEqualTo(const ArchSpec &rhs, bool exact_match) const {
// explicitly ignoring m_distribution_id in this method.
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
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;
Removed the == and != operators from ArchSpec, since equality can be strict or loose and we want code to explicitly choose one or the other. Also renamed the Compare function to IsEqualTo, to avoid confusion. <rdar://problem/12856749> llvm-svn: 170152
2012-12-14 06:07:14 +08:00
const ArchSpec::Core lhs_core = GetCore();
const ArchSpec::Core rhs_core = rhs.GetCore();
*** 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
Removed the == and != operators from ArchSpec, since equality can be strict or loose and we want code to explicitly choose one or the other. Also renamed the Compare function to IsEqualTo, to avoid confusion. <rdar://problem/12856749> llvm-svn: 170152
2012-12-14 06:07:14 +08:00
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
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
if (core_match) {
const llvm::Triple &lhs_triple = GetTriple();
const llvm::Triple &rhs_triple = rhs.GetTriple();
*** 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
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
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) {
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
const bool rhs_vendor_specified = rhs.TripleVendorWasSpecified();
const bool lhs_vendor_specified = TripleVendorWasSpecified();
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// Both architectures had the vendor specified, so if they aren't equal
// then we return false
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
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;
// Only fail if both vendor types are not unknown
if (lhs_triple_vendor != llvm::Triple::UnknownVendor &&
rhs_triple_vendor != llvm::Triple::UnknownVendor)
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;
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
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
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) {
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
const bool rhs_os_specified = rhs.TripleOSWasSpecified();
const bool lhs_os_specified = TripleOSWasSpecified();
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// Both architectures had the OS specified, so if they aren't equal then
// we return false
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
if (rhs_os_specified && lhs_os_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
Cleanup the iOS simulator code. Fixes include: - Don't say that "<arch>-apple-ios" is compatible with "<arch>-apple-macosx" - Fixed DynamicLoaderMacOSXDYLD so specify an architecture that was converted solely from a cputype and subtype, just specify the file + UUID. - Fixed PlatformiOSSimulator::GetSupportedArchitectureAtIndex() so it returns the correct archs - Fixed SymbolFileDWARFDebugMap to load .o files correctly by just specifying the architecture without the vendor and OS now that "<arch>-apple-ios" is not compatible with "<arch>-apple-macosx" so we can load .o files correctly for DWARF with debug map - Fixed the coded in TargetList::CreateTarget() so it does the right thing with an underspecified triple where just the arch is specified. llvm-svn: 212783
2014-07-11 07:33:37 +08:00
// Only fail if both os types are not unknown
if (lhs_triple_os != llvm::Triple::UnknownOS &&
rhs_triple_os != llvm::Triple::UnknownOS)
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
}
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
const llvm::Triple::EnvironmentType lhs_triple_env =
lhs_triple.getEnvironment();
const llvm::Triple::EnvironmentType rhs_triple_env =
rhs_triple.getEnvironment();
*** 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
Simplify Boolean expressions This patch simplifies boolean expressions acorss LLDB. It was generated using clang-tidy with the following command: run-clang-tidy.py -checks='-*,readability-simplify-boolean-expr' -format -fix $PWD Differential revision: https://reviews.llvm.org/D55584 llvm-svn: 349215
2018-12-15 08:15:33 +08:00
return IsCompatibleEnvironment(lhs_triple_env, rhs_triple_env);
*** 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
}
Cleanup the iOS simulator code. Fixes include: - Don't say that "<arch>-apple-ios" is compatible with "<arch>-apple-macosx" - Fixed DynamicLoaderMacOSXDYLD so specify an architecture that was converted solely from a cputype and subtype, just specify the file + UUID. - Fixed PlatformiOSSimulator::GetSupportedArchitectureAtIndex() so it returns the correct archs - Fixed SymbolFileDWARFDebugMap to load .o files correctly by just specifying the architecture without the vendor and OS now that "<arch>-apple-ios" is not compatible with "<arch>-apple-macosx" so we can load .o files correctly for DWARF with debug map - Fixed the coded in TargetList::CreateTarget() so it does the right thing with an underspecified triple where just the arch is specified. llvm-svn: 212783
2014-07-11 07:33:37 +08:00
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
}
Recompute ArchSpec core after MergeFrom Summary: MergeFrom was updating the architecture if the target triple did not have it set. However, it was leaving the core field as invalid. This resulted in assertion failures in core file tests as a missing core meant we were unable to compute the address byte size properly. Add a unit test for the new behaviour. Reviewers: jingham, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D32221 llvm-svn: 300836
2017-04-20 20:30:18 +08:00
void ArchSpec::UpdateCore() {
llvm::StringRef arch_name(m_triple.getArchName());
const CoreDefinition *core_def = FindCoreDefinition(arch_name);
if (core_def) {
m_core = core_def->core;
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// 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
Recompute ArchSpec core after MergeFrom Summary: MergeFrom was updating the architecture if the target triple did not have it set. However, it was leaving the core field as invalid. This resulted in assertion failures in core file tests as a missing core meant we were unable to compute the address byte size properly. Add a unit test for the new behaviour. Reviewers: jingham, clayborg Subscribers: lldb-commits Differential Revision: https://reviews.llvm.org/D32221 llvm-svn: 300836
2017-04-20 20:30:18 +08:00
m_byte_order = core_def->default_byte_order;
} else {
Clear();
}
}
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.
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.
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
static bool cores_match(const ArchSpec::Core core1, const ArchSpec::Core core2,
bool try_inverse, bool enforce_exact_match) {
if (core1 == core2)
Mark armv7em and armv7m as compatible architectures. <rdar://problem/21244671> llvm-svn: 240713
2015-06-26 06:37:57 +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
<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
switch (core1) {
Initial patch for supporting Hexagon DSP llvm-svn: 201665
2014-02-19 19:16:46 +08:00
case ArchSpec::kCore_any:
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
Allow generic ARM cores to match any more specific ARM architecture. <rdar://problem/15932248> llvm-svn: 212863
2014-07-12 08:11:34 +08:00
case ArchSpec::eCore_arm_generic:
if (enforce_exact_match)
*** 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;
Add -Wimplicit-fallthrough command line option to clang in the xcode project file to catch switch statements that have a case that falls through unintentionally. Define LLVM_FALLTHROUGH to indicate instances where a case has code and intends to fall through. This should be in llvm/Support/Compiler.h; Peter Collingbourne originally checked in there (r237766), then reverted (r237941) because he didn't have time to mark up all the 'case' statements that were intended to fall through. I put together a patch to get this back in llvm http://reviews.llvm.org/D17063 but it hasn't been approved in the past week. I added a new lldb-private-defines.h to hold the definition for now. Every place in lldb where there is a comment that the fall-through is intentional, I added LLVM_FALLTHROUGH to silence the warning. I haven't tried to identify whether the fallthrough is a bug or not in the other places. I haven't tried to add this to the cmake option build flags. This warning will only work for clang. This build cleanly (with some new warnings) on macosx with clang under xcodebuild, but if this causes problems for people on other configurations, I'll back it out. llvm-svn: 260930
2016-02-16 12:14:33 +08:00
LLVM_FALLTHROUGH;
<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
case ArchSpec::kCore_arm_any:
if (core2 >= ArchSpec::kCore_arm_first && core2 <= ArchSpec::kCore_arm_last)
Mark armv7em and armv7m as compatible architectures. <rdar://problem/21244671> llvm-svn: 240713
2015-06-26 06:37:57 +08:00
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
if (core2 >= ArchSpec::kCore_thumb_first &&
core2 <= ArchSpec::kCore_thumb_last)
Mark armv7em and armv7m as compatible architectures. <rdar://problem/21244671> llvm-svn: 240713
2015-06-26 06:37:57 +08:00
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
if (core2 == ArchSpec::kCore_arm_any)
Mark armv7em and armv7m as compatible architectures. <rdar://problem/21244671> llvm-svn: 240713
2015-06-26 06:37:57 +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
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
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))
Mark armv7em and armv7m as compatible architectures. <rdar://problem/21244671> llvm-svn: 240713
2015-06-26 06:37:57 +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
break;
Fix supported architectures on PlatformWindows. i386, i486, i486sx, and i686 are all indistinguishable as far as PE/COFF files are concerned. This patch adds support for all of these architectures to PlatformWindows. Differential Revision: http://reviews.llvm.org/D4658 llvm-svn: 214092
2014-07-29 00:44:49 +08:00
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))
Mark armv7em and armv7m as compatible architectures. <rdar://problem/21244671> llvm-svn: 240713
2015-06-26 06:37:57 +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
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
case ArchSpec::kCore_ppc_any:
if ((core2 >= ArchSpec::kCore_ppc_first &&
core2 <= ArchSpec::kCore_ppc_last) ||
(core2 == ArchSpec::kCore_ppc_any))
Mark armv7em and armv7m as compatible architectures. <rdar://problem/21244671> llvm-svn: 240713
2015-06-26 06:37:57 +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
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
case ArchSpec::kCore_ppc64_any:
if ((core2 >= ArchSpec::kCore_ppc64_first &&
core2 <= ArchSpec::kCore_ppc64_last) ||
(core2 == ArchSpec::kCore_ppc64_any))
Mark armv7em and armv7m as compatible architectures. <rdar://problem/21244671> llvm-svn: 240713
2015-06-26 06:37:57 +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
break;
Add definitions for "armv6m", which indicates a Cortex-M0 processor. It uses the T16 and a few T32 instructions from the ARMv7-A ISA. <rdar://problem/15099306> llvm-svn: 191587
2013-09-28 07:21:54 +08:00
case ArchSpec::eCore_arm_armv6m:
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
if (!enforce_exact_match) {
Allow generic ARM cores to match any more specific ARM architecture. <rdar://problem/15932248> llvm-svn: 212863
2014-07-12 08:11:34 +08:00
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;
Allow generic ARM cores to match any more specific ARM architecture. <rdar://problem/15932248> llvm-svn: 212863
2014-07-12 08:11:34 +08:00
try_inverse = 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
if (core2 == ArchSpec::eCore_arm_armv7)
return true;
Mark armv7em and armv7m as compatible architectures. <rdar://problem/21244671> llvm-svn: 240713
2015-06-26 06:37:57 +08:00
if (core2 == ArchSpec::eCore_arm_armv6m)
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
}
break;
Initial patch for supporting Hexagon DSP llvm-svn: 201665
2014-02-19 19:16:46 +08:00
case ArchSpec::kCore_hexagon_any:
if ((core2 >= ArchSpec::kCore_hexagon_first &&
core2 <= ArchSpec::kCore_hexagon_last) ||
(core2 == ArchSpec::kCore_hexagon_any))
lldb.LLDB_ARCH_DEFAULT now works correctly on Macs with haswell enabled kernels. <rdar://problem/17604133> llvm-svn: 213004
2014-07-15 06:53:02 +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
break;
Re-commit the (fixed) changes from r248985 which were reverted by Pavel when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
2015-10-09 05:48:35 +08:00
// v. https://en.wikipedia.org/wiki/ARM_Cortex-M#Silicon_customization
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// Cortex-M0 - ARMv6-M - armv6m Cortex-M3 - ARMv7-M - armv7m Cortex-M4 -
// ARMv7E-M - armv7em
Add recognition of two more armv7 variants, armv7m and armv7em. <rdar://problem/13361372> llvm-svn: 176674
2013-03-08 09:20:17 +08:00
case ArchSpec::eCore_arm_armv7em:
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
if (!enforce_exact_match) {
Allow generic ARM cores to match any more specific ARM architecture. <rdar://problem/15932248> llvm-svn: 212863
2014-07-12 08:11:34 +08:00
if (core2 == ArchSpec::eCore_arm_generic)
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
return true;
Mark armv7em and armv7m as compatible architectures. <rdar://problem/21244671> llvm-svn: 240713
2015-06-26 06:37:57 +08:00
if (core2 == ArchSpec::eCore_arm_armv7m)
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
return true;
Mark armv7em and armv7m as compatible architectures. <rdar://problem/21244671> llvm-svn: 240713
2015-06-26 06:37:57 +08:00
if (core2 == ArchSpec::eCore_arm_armv6m)
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
return 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
if (core2 == ArchSpec::eCore_arm_armv7)
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
return true;
Mark armv7em and armv7m as compatible architectures. <rdar://problem/21244671> llvm-svn: 240713
2015-06-26 06:37:57 +08:00
try_inverse = 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
}
break;
Re-commit the (fixed) changes from r248985 which were reverted by Pavel when they introduced android testsuite regressions. Pavel has run the testsuite against the updated patch and it completes cleanly now. The original commit message: Fixing a subtle issue on Mac OS X systems with dSYMs (possibly introduced by r235737 but I didn't look into it too closely). A dSYM can have a per-UUID plist in it which tells lldb where to find an executable binary for the dSYM (DBGSymbolRichExecutable) - other information can be included in this plist, like how to remap the source file paths from their build pathnames to their long-term storage pathnames. This per-UUID plist is a unusual; it is used probably exclusively inside apple with our build system. It is not created by default in normal dSYMs. The problem was like this: 1. lldb wants to find an executable, given only a UUID (this happens when lldb is doing cross-host debugging and doesn't have a copy of the target system's binaries) 2. It eventually calls LocateMacOSXFilesUsingDebugSymbols which does a spotlight search for the dSYM on the local system, and failing that, tries the DBGShellCommands command to find the dSYM. 3. It gets a dSYM. It reads the per-UUID plist in the dSYM. The dSYM has a DBGSymbolRichExecutable kv pair pointing to the binary on a network filesystem. 4. Using the binary on the network filesystem, lldb now goes to find the dSYM. 5. It starts by looking for a dSYM next to the binary it found. 6. lldb is now reading the dSYM over a network filesystem, ignoring the one it found on its local filesystem earlier. Everything still *works* but it's much slower. This would be a tricky one to write up in a testsuite case; you really need the binary to not exist on the local system. And LocateMacOSXFilesUsingDebugSymbols will only compile on Mac OS X - even if I found a way to write up a test case, it would not run anywhere but on a mac. One change Greg wanted while I was touching this code was to have LocateMacOSXFilesUsingDebugSymbols (which could be asked to find a binary OR find a dSYM) to instead return a ModuleSpec with the sum total of everything it could find. This change of passing around a ModuleSpec instead of a FileSpec was percolated up into ModuleList::GetSharedModule. The changes to LocateMacOSXFilesUsingDebugSymbols look larger than they really are - there's a lot of simple whitespace changes in there. I ran the testsuites on mac, no new regressions introduced <rdar://problem/21993813> llvm-svn: 249755
2015-10-09 05:48:35 +08:00
// v. https://en.wikipedia.org/wiki/ARM_Cortex-M#Silicon_customization
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// Cortex-M0 - ARMv6-M - armv6m Cortex-M3 - ARMv7-M - armv7m Cortex-M4 -
// ARMv7E-M - armv7em
Mark armv7em and armv7m as compatible architectures. <rdar://problem/21244671> llvm-svn: 240713
2015-06-26 06:37:57 +08:00
case ArchSpec::eCore_arm_armv7m:
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
if (!enforce_exact_match) {
Allow generic ARM cores to match any more specific ARM architecture. <rdar://problem/15932248> llvm-svn: 212863
2014-07-12 08:11:34 +08:00
if (core2 == ArchSpec::eCore_arm_generic)
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
return true;
Mark armv7em and armv7m as compatible architectures. <rdar://problem/21244671> llvm-svn: 240713
2015-06-26 06:37:57 +08:00
if (core2 == ArchSpec::eCore_arm_armv6m)
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
return 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
if (core2 == ArchSpec::eCore_arm_armv7)
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
return true;
Mark armv7em and armv7m as compatible architectures. <rdar://problem/21244671> llvm-svn: 240713
2015-06-26 06:37:57 +08:00
if (core2 == ArchSpec::eCore_arm_armv7em)
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
return true;
Mark armv7em and armv7m as compatible architectures. <rdar://problem/21244671> llvm-svn: 240713
2015-06-26 06:37:57 +08:00
try_inverse = 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
}
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
<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
case ArchSpec::eCore_arm_armv7f:
rdar://problem/11374963 Fix a subtle ArchSpec::cores_match() logic issue which prevents the add-dsym command to add a debug symbol file to one of the target's current modules. llvm-svn: 162802
2012-08-29 06:53:40 +08:00
case ArchSpec::eCore_arm_armv7k:
<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
case ArchSpec::eCore_arm_armv7s:
[LLDB] Add core definition for armv8l and armv7l This patch adds core definitions in lldb ArchSpecs for armv8l and armv7l cores. This was needed because on Linux running on 32-bit Arm v8 we are returned armv8l in case we are running 32-bit sysroot on 64bit kernel. In case of 32-bit kernel and 32-bit sysroot running on arm v8 hardware we are returned armv7l. This is quite common when we run 32 bit arm using docker container. Signed-off-by: Muhammad Omair Javaid <omair.javaid@linaro.org> Differential Revision: https://reviews.llvm.org/D69904
2019-11-13 08:30:25 +08:00
case ArchSpec::eCore_arm_armv7l:
case ArchSpec::eCore_arm_armv8l:
[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
if (!enforce_exact_match) {
Allow generic ARM cores to match any more specific ARM architecture. <rdar://problem/15932248> llvm-svn: 212863
2014-07-12 08:11:34 +08:00
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;
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
if (core2 == ArchSpec::eCore_arm_armv7)
[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
return true;
try_inverse = 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
}
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
Fix supported architectures on PlatformWindows. i386, i486, i486sx, and i686 are all indistinguishable as far as PE/COFF files are concerned. This patch adds support for all of these architectures to PlatformWindows. Differential Revision: http://reviews.llvm.org/D4658 llvm-svn: 214092
2014-07-29 00:44:49 +08:00
case ArchSpec::eCore_x86_64_x86_64h:
Add definitions for "armv6m", which indicates a Cortex-M0 processor. It uses the T16 and a few T32 instructions from the ARMv7-A ISA. <rdar://problem/15099306> llvm-svn: 191587
2013-09-28 07:21:54 +08:00
if (!enforce_exact_match) {
Initial patch for supporting Hexagon DSP llvm-svn: 201665
2014-02-19 19:16:46 +08:00
try_inverse = false;
Mark armv7em and armv7m as compatible architectures. <rdar://problem/21244671> llvm-svn: 240713
2015-06-26 06:37:57 +08:00
if (core2 == ArchSpec::eCore_x86_64_x86_64)
Allow generic ARM cores to match any more specific ARM architecture. <rdar://problem/15932248> llvm-svn: 212863
2014-07-12 08:11:34 +08:00
return true;
lldb.LLDB_ARCH_DEFAULT now works correctly on Macs with haswell enabled kernels. <rdar://problem/17604133> llvm-svn: 213004
2014-07-15 06:53:02 +08:00
}
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
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
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;
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;
}
Fix all of the unannotated switch cases to annotate the fall through or do the right thing and break. llvm-svn: 261950
2016-02-26 09:20:20 +08:00
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
[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
case ArchSpec::eCore_arm_arm64:
[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
if (!enforce_exact_match) {
if (core2 == ArchSpec::eCore_arm_aarch64)
[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
return true;
[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
if (core2 == ArchSpec::eCore_arm_armv8)
return true;
try_inverse = false;
}
Fix all of the unannotated switch cases to annotate the fall through or do the right thing and break. llvm-svn: 261950
2016-02-26 09:20:20 +08:00
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
Add arm64_32 support to lldb, an ILP32 codegen that runs on arm64 ISA targets, specifically Apple watches. Differential Revision: https://reviews.llvm.org/D68858 llvm-svn: 375032
2019-10-17 03:14:49 +08:00
case ArchSpec::eCore_arm_arm64_32:
if (!enforce_exact_match) {
if (core2 == ArchSpec::eCore_arm_generic)
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
case ArchSpec::eCore_mips32:
if (!enforce_exact_match) {
if (core2 >= ArchSpec::kCore_mips32_first &&
core2 <= ArchSpec::kCore_mips32_last)
return true;
try_inverse = false;
}
Fix all of the unannotated switch cases to annotate the fall through or do the right thing and break. llvm-svn: 261950
2016-02-26 09:20:20 +08:00
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
[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
case ArchSpec::eCore_mips32el:
if (!enforce_exact_match) {
if (core2 >= ArchSpec::kCore_mips32el_first &&
core2 <= ArchSpec::kCore_mips32el_last)
return true;
[LLDB][MIPS] Core Dump Support. Reviewers: labath, emaste Subscribers: jaydeep, bhushan, lldb-commits, slthakur Differential Revision: https://reviews.llvm.org/D30457 llvm-svn: 299200
2017-03-31 19:14:02 +08:00
try_inverse = true;
[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
}
break;
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;
[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
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;
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
try_inverse = false;
[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
}
break;
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;
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
try_inverse = false;
[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
}
break;
case ArchSpec::eCore_mips64r2el:
[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
case ArchSpec::eCore_mips64r3el:
case ArchSpec::eCore_mips64r5el:
[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
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;
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
try_inverse = false;
[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
}
break;
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;
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;
case ArchSpec::eCore_mips32r6:
if (!enforce_exact_match) {
if (core2 == ArchSpec::eCore_mips32 || core2 == ArchSpec::eCore_mips32r6)
return true;
}
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
case ArchSpec::eCore_mips32r6el:
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
if (!enforce_exact_match) {
[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
if (core2 == ArchSpec::eCore_mips32el ||
core2 == ArchSpec::eCore_mips32r6el)
<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
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
case ArchSpec::eCore_mips64r6:
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
if (!enforce_exact_match) {
[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
if (core2 == ArchSpec::eCore_mips32 || core2 == ArchSpec::eCore_mips32r6)
return true;
if (core2 == ArchSpec::eCore_mips64 || core2 == ArchSpec::eCore_mips64r6)
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
}
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
case ArchSpec::eCore_mips64r6el:
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
if (!enforce_exact_match) {
[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
if (core2 == ArchSpec::eCore_mips32el ||
core2 == ArchSpec::eCore_mips32r6el)
return true;
if (core2 == ArchSpec::eCore_mips64el ||
core2 == ArchSpec::eCore_mips64r6el)
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
}
break;
default:
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
if (try_inverse)
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 cores_match(core2, core1, false, enforce_exact_match);
<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 false;
}
Initial checkin of lldb code from internal Apple repo. llvm-svn: 105619
2010-06-09 00:52:24 +08:00
bool lldb_private::operator<(const ArchSpec &lhs, const ArchSpec &rhs) {
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
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
Remove ObjectFile usage from HostLinux::GetProcessInfo Summary: The ObjectFile class was used to determine the architecture of a running process by inspecting it's main executable. There were two issues with this: - it's in the wrong layer - the call can be very expensive (it can end up computing the crc of the whole file). Since the process is running on the host, ideally we would be able to just query the data straight from the OS like darwin does, but there doesn't seem to be a reasonable way to do that. So, this fixes the layering issue by using the llvm object library to inspect the file. Since we know the process is already running on the host, we just need to peek at a few bytes of the elf header to determine whether it's 32- or 64-bit (which should make this faster as well). Pretty much the same logic was implemented in NativeProcessProtocol::ResolveProcessArchitecture, so I delete this logic and replace calls with GetProcessInfo. Reviewers: eugene, krytarowski Subscribers: mgorny, hintonda, lldb-commits Differential Revision: https://reviews.llvm.org/D42488 llvm-svn: 323637
2018-01-29 18:46:00 +08:00
bool lldb_private::operator==(const ArchSpec &lhs, const ArchSpec &rhs) {
return lhs.GetCore() == rhs.GetCore();
}
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
bool ArchSpec::IsFullySpecifiedTriple() const {
const auto &user_specified_triple = GetTriple();
*** 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
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
bool user_triple_fully_specified = 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
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
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;
}
}
*** 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
}
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
return user_triple_fully_specified;
}
void ArchSpec::PiecewiseTripleCompare(
const ArchSpec &other, bool &arch_different, bool &vendor_different,
Move StopInfoOverride callback to the new architecture plugin This creates a new Architecture plugin and moves the stop info override callback to this place. The motivation for this is to remove complex dependencies from the ArchSpec class because it is used in a lot of places that (should) know nothing about Process instances and StopInfo objects. I also add a test for the functionality covered by the override callback. Differential Revision: https://reviews.llvm.org/D31172 llvm-svn: 316609
2017-10-26 05:05:31 +08:00
bool &os_different, bool &os_version_different, bool &env_different) const {
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
const llvm::Triple &me(GetTriple());
const llvm::Triple &them(other.GetTriple());
*** 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
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
arch_different = (me.getArch() != them.getArch());
*** 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
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
vendor_different = (me.getVendor() != them.getVendor());
*** 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
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
os_different = (me.getOS() != them.getOS());
*** 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
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
os_version_different = (me.getOSMajorVersion() != them.getOSMajorVersion());
*** 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
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
env_different = (me.getEnvironment() != them.getEnvironment());
}
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
bool ArchSpec::IsAlwaysThumbInstructions() const {
Rename Error -> Status. This renames the LLDB error class to Status, as discussed on the lldb-dev mailing list. A change of this magnitude cannot easily be done without find and replace, but that has potential to catch unwanted occurrences of common strings such as "Error". Every effort was made to find all the obvious things such as the word "Error" appearing in a string, etc, but it's possible there are still some lingering occurences left around. Hopefully nothing too serious. llvm-svn: 302872
2017-05-12 12:51:55 +08:00
std::string Status;
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
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:
//
Reflow paragraphs in comments. This is intended as a clean up after the big clang-format commit (r280751), which unfortunately resulted in many of the comment paragraphs in LLDB being very hard to read. FYI, the script I used was: import textwrap import commands import os import sys import re tmp = "%s.tmp"%sys.argv[1] out = open(tmp, "w+") with open(sys.argv[1], "r") as f: header = "" text = "" comment = re.compile(r'^( *//) ([^ ].*)$') special = re.compile(r'^((([A-Z]+[: ])|([0-9]+ )).*)|(.*;)$') for line in f: match = comment.match(line) if match and not special.match(match.group(2)): # skip intentionally short comments. if not text and len(match.group(2)) < 40: out.write(line) continue if text: text += " " + match.group(2) else: header = match.group(1) text = match.group(2) continue if text: filled = textwrap.wrap(text, width=(78-len(header)), break_long_words=False) for l in filled: out.write(header+" "+l+'\n') text = "" out.write(line) os.rename(tmp, sys.argv[1]) Differential Revision: https://reviews.llvm.org/D46144 llvm-svn: 331197
2018-05-01 00:49:04 +08:00
// Cortex-M0, Cortex-M0+, Cortex-M1: armv6m Cortex-M3: armv7m Cortex-M4,
// Cortex-M7: armv7em
*** 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
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
if (GetCore() == ArchSpec::Core::eCore_arm_armv7m ||
GetCore() == ArchSpec::Core::eCore_arm_armv7em ||
Enable the fp-armv8 disassembler feature when disassembling Cortex-M code. This will enable disassembly of the optional subset of neon that some Cortex cores support. Add a unit test to check that a few of these instructions disassemble as expected. <rdar://problem/26674303> llvm-svn: 341623
2018-09-07 09:28:48 +08:00
GetCore() == ArchSpec::Core::eCore_arm_armv6m ||
GetCore() == ArchSpec::Core::eCore_thumbv7m ||
GetCore() == ArchSpec::Core::eCore_thumbv7em ||
GetCore() == ArchSpec::Core::eCore_thumbv6m) {
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
return true;
}
[LLDB] Always interpret arm instructions as thumb on windows Windows on ARM always uses thumb mode, and doesn't have most of the mechanisms that are used in e.g. ELF for distinguishing between arm and thumb. Differential Revision: https://reviews.llvm.org/D70796
2019-10-16 05:05:06 +08:00
// Windows on ARM is always thumb.
if (GetTriple().isOSWindows())
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
}
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
return false;
}
[lldb][NFC] Migrate to raw_ostream in ArchSpec::DumpTriple Reviewers: labath, davide Reviewed By: davide Subscribers: clayborg, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70979
2019-12-04 15:27:43 +08:00
void ArchSpec::DumpTriple(llvm::raw_ostream &s) const {
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
const llvm::Triple &triple = GetTriple();
llvm::StringRef arch_str = triple.getArchName();
llvm::StringRef vendor_str = triple.getVendorName();
llvm::StringRef os_str = triple.getOSName();
Print environment when dumping arch triple Summary: Print environment from triple if it exists. Reviewers: tfiala, clayborg Subscribers: lldb-commits, sas Differential Revision: http://reviews.llvm.org/D18620 Change by Francis Ricci <fjricci@fb.com> llvm-svn: 265420
2016-04-06 01:29:19 +08:00
llvm::StringRef environ_str = triple.getEnvironmentName();
*** 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][NFC] Migrate to raw_ostream in ArchSpec::DumpTriple Reviewers: labath, davide Reviewed By: davide Subscribers: clayborg, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70979
2019-12-04 15:27:43 +08:00
s << llvm::formatv("{0}-{1}-{2}", arch_str.empty() ? "*" : arch_str,
vendor_str.empty() ? "*" : vendor_str,
os_str.empty() ? "*" : os_str);
*** 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
Print environment when dumping arch triple Summary: Print environment from triple if it exists. Reviewers: tfiala, clayborg Subscribers: lldb-commits, sas Differential Revision: http://reviews.llvm.org/D18620 Change by Francis Ricci <fjricci@fb.com> llvm-svn: 265420
2016-04-06 01:29:19 +08:00
if (!environ_str.empty())
[lldb][NFC] Migrate to raw_ostream in ArchSpec::DumpTriple Reviewers: labath, davide Reviewed By: davide Subscribers: clayborg, JDevlieghere, lldb-commits Tags: #lldb Differential Revision: https://reviews.llvm.org/D70979
2019-12-04 15:27:43 +08:00
s << "-" << environ_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
}