This patch is to address a few issues I came up with when working on an armcc-generated ELF binary being run on a Cortex-M4 core with lldb. The first problem is that the elf binary comes in as a generic "arm" triple ("arm--") and the second is that we don't see to get any arm/thumb hints about the functions in this binary.
This is a Cortex-M4 ("armv7em") so the instructions are always thumb.
When lldb calls the instruction unwinder (FuncUnwinders::GetUnwindAssemblyProfiler) it gets the object file's arch and merges in the Target's arch via ArchSpec::MergeFrom. The object file has "arm--", the target has "armv7em-unknown-unknown". The changes to MergeFrom allow us to replace the "arm" cpu part of the triple with the Target's "armv7em".
I wanted to centralize the "Cortex M0-M7 are always thumb" special knowledge a little better - we already had two examples where we were checking against specific core types (armv6m, armv7m, armv7em) in the disassembler. So I added a method to ArchSpec to check that. It's a very arm specific method name, but it seems a bit of an arm specific problem that we're trying to identify here.
Down in the instruction emulation I use the ArchSpec method to make sure we don't try to emulate anything as arm because we're missing the arm/thumb hints from the ObjectFile.
I imagine at some point I'll want to do something in SysV-Arm ABI plugin for the DefaultUnwindPlan to say that if this core is always running thumb instructions, the frame pointer is r7 for instance. That default UnwindPlan which uses the arm r11 as a frame pointer is a problem for the unwinder's behavior in a real mixed arm/thumb environment - we sidestep it inside Apple be using r7 as the frame pointer for both types of code.
Tamas, I put you as the reviewer because this is closest to what you work on regularly. Please let me know what you think when you have a chance.