When ObjectFileMachO reads a Mach-O file for a 32-bit arm cpu,

set the triple's "vendor" field to Apple.  

We don't want to assume a vendor of Apple for all Mach-O files -
this breaks x86_64 EFI debugging where they put non-Apple binaries
in a Mach-O format for ease of handling.

But on armv7, Apple's ABI always uses r7 as the frame pointer
register; if we don't set the Vendor field to Apple, we can pick
up a generic armv7 ABI where the fp is r11 (or r7 for thumb) which
breaks backtracing altogether.

Greg is reluctant for us to make any assumptions about the Vendor
here, but we'll see how this shakes out.  It's such a big problem
on armv7 if we don't know this is using the Apple ABI that it's worth
trying this approach.

<rdar://problem/22137561> 

llvm-svn: 258387
This commit is contained in:
Jason Molenda 2016-01-21 04:38:05 +00:00
parent de008d338c
commit 1a75b0d14f
1 changed files with 16 additions and 3 deletions

View File

@ -4828,9 +4828,22 @@ ObjectFileMachO::GetArchitecture (const llvm::MachO::mach_header &header,
if (header.filetype == MH_PRELOAD)
{
// Set vendor to an unspecified unknown or a "*" so it can match any vendor
triple.setVendor(llvm::Triple::UnknownVendor);
triple.setVendorName(llvm::StringRef());
if (header.cputype == CPU_TYPE_ARM)
{
// If this is a 32-bit arm binary, and it's a standalone binary,
// force the Vendor to Apple so we don't accidentally pick up
// the generic armv7 ABI at runtime. Apple's armv7 ABI always uses
// r7 for the frame pointer register; most other armv7 ABIs use a
// combination of r7 and r11.
triple.setVendor(llvm::Triple::Apple);
}
else
{
// Set vendor to an unspecified unknown or a "*" so it can match any vendor
// This is required for correct behavior of EFI debugging on x86_64
triple.setVendor(llvm::Triple::UnknownVendor);
triple.setVendorName(llvm::StringRef());
}
return true;
}
else