diff options
author | Greg Clayton <gclayton@apple.com> | 2011-02-23 00:35:02 +0000 |
---|---|---|
committer | Greg Clayton <gclayton@apple.com> | 2011-02-23 00:35:02 +0000 |
commit | 64195a2c8bd8166e2e70dcac6d5b3a88fbb1f910 (patch) | |
tree | 4371f2a424bba44b326674edd497630e91e89f00 /lldb/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp | |
parent | 37de3235e5a85c4d3cff8edc71e214a1a18aa21f (diff) | |
download | bcm5719-llvm-64195a2c8bd8166e2e70dcac6d5b3a88fbb1f910.tar.gz bcm5719-llvm-64195a2c8bd8166e2e70dcac6d5b3a88fbb1f910.zip |
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
Diffstat (limited to 'lldb/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp')
-rw-r--r-- | lldb/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp | 6 |
1 files changed, 3 insertions, 3 deletions
diff --git a/lldb/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp b/lldb/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp index 2d9e0210929..f712fd92c54 100644 --- a/lldb/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp +++ b/lldb/source/Plugins/Process/Utility/UnwindMacOSXFrameBackchain.cpp @@ -32,12 +32,12 @@ UnwindMacOSXFrameBackchain::GetFrameCount() { if (m_cursors.empty()) { - const ArchSpec target_arch (m_thread.GetProcess().GetTarget().GetArchitecture ()); + const ArchSpec& target_arch = m_thread.GetProcess().GetTarget().GetArchitecture (); // Frame zero should always be supplied by the thread... StackFrameSP frame_sp (m_thread.GetStackFrameAtIndex (0)); - if (target_arch == ArchSpec("x86_64")) + if (target_arch.GetMachine() == llvm::Triple::x86_64) GetStackFrameData_x86_64 (frame_sp.get()); - else if (target_arch == ArchSpec("i386")) + else if (target_arch.GetMachine() == llvm::Triple::x86) GetStackFrameData_i386 (frame_sp.get()); } |