Revert r201292 which relaxed the stack frame alignment requirements.
authorJason Molenda <jmolenda@apple.com>
Thu, 13 Feb 2014 23:29:36 +0000 (23:29 +0000)
committerJason Molenda <jmolenda@apple.com>
Thu, 13 Feb 2014 23:29:36 +0000 (23:29 +0000)
This was primarily working around problems where we weren't able
to identify trap handlers for different environments -- but instead,
I'm working to make it easier to specify those trap handler function
names.

llvm-svn: 201366

lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.cpp
lldb/source/Plugins/ABI/MacOSX-i386/ABIMacOSX_i386.h
lldb/source/Plugins/ABI/SysV-x86_64/ABISysV_x86_64.h
lldb/source/Plugins/DynamicLoader/POSIX-DYLD/DynamicLoaderPOSIXDYLD.cpp

index 8596381..f360a18 100644 (file)
@@ -235,12 +235,22 @@ ABIMacOSX_i386::GetRedZoneSize () const
 ABISP
 ABIMacOSX_i386::CreateInstance (const ArchSpec &arch)
 {
-    static ABISP g_abi_sp;
-     if (arch.GetTriple().getArch() == llvm::Triple::x86)
-     {
-        if (!g_abi_sp)
-            g_abi_sp.reset (new ABIMacOSX_i386);
-        return g_abi_sp;
+    static ABISP g_abi_mac_sp;
+    static ABISP g_abi_other_sp;
+    if (arch.GetTriple().getArch() == llvm::Triple::x86)
+    {
+        if (arch.GetTriple().isOSDarwin())
+        {
+            if (!g_abi_mac_sp)
+                g_abi_mac_sp.reset (new ABIMacOSX_i386(true));
+            return g_abi_mac_sp;
+        }
+        else
+        {
+            if (!g_abi_other_sp)
+                g_abi_other_sp.reset (new ABIMacOSX_i386(false));
+            return g_abi_other_sp;
+        }
     }
     return ABISP();
 }
index 43784a5..a2eee28 100644 (file)
@@ -71,25 +71,24 @@ public:
         return true;
     }
     
-    // The Darwin i386 ABI requires that stack frames be 16 byte aligned.
-    // When there is a trap handler on the stack, e.g. _sigtramp in userland
-    // code, we've seen that the stack pointer is often not aligned properly
-    // before the handler is invoked.  This means that lldb will stop the unwind
-    // early -- before the function which caused the trap.
-    //
-    // To work around this, we relax that alignment to be just word-size (4-bytes).
-    // Whitelisting the trap handlers for user space would be easy (_sigtramp) but
-    // in other environments there can be a large number of different functions
-    // involved in async traps.
-    //
-    // If we were to enforce 16-byte alignment, we also need to relax to 4-byte
-    // alignment for non-darwin i386 targets.
     virtual bool
     CallFrameAddressIsValid (lldb::addr_t cfa)
     {
-        // Make sure the stack call frame addresses are are 4 byte aligned
-        if (cfa & (4ull - 1ull))
-            return false;   // Not 4 byte aligned
+        // Darwin call frame addresses must be 16-byte aligned, but other OS's
+        // only need 4-byte alignment.  Otherwise the ABI matches, so we have
+        // this one minor override here.
+        if (target_is_darwin)
+        {
+            // Make sure the stack call frame addresses are are 16 byte aligned
+            if (cfa & (16ull - 1ull))
+                return false;   // Not 16 byte aligned
+        }
+        else
+        {
+            // Make sure the stack call frame addresses are are 4 byte aligned
+            if (cfa & (4ull - 1ull))
+                return false;   // Not 4 byte aligned
+        }
         if (cfa == 0)
             return false;   // Zero is not a valid stack address
         return true;
@@ -140,7 +139,11 @@ protected:
     RegisterIsCalleeSaved (const lldb_private::RegisterInfo *reg_info);
 
 private:
-    ABIMacOSX_i386() : lldb_private::ABI() { } // Call CreateInstance instead.
+    ABIMacOSX_i386(bool is_darwin) : lldb_private::ABI(), 
+                                     target_is_darwin(is_darwin) 
+                                   { } // Call CreateInstance instead.
+
+    bool target_is_darwin;
 };
 
 
index 7fd1b6c..5ccb6e5 100644 (file)
@@ -68,22 +68,12 @@ public:
         return true;
     }
     
-    // The SysV x86_64 ABI requires that stack frames be 16 byte aligned.
-    // When there is a trap handler on the stack, e.g. _sigtramp in userland
-    // code, we've seen that the stack pointer is often not aligned properly
-    // before the handler is invoked.  This means that lldb will stop the unwind
-    // early -- before the function which caused the trap.
-    //
-    // To work around this, we relax that alignment to be just word-size (8-bytes).
-    // Whitelisting the trap handlers for user space would be easy (_sigtramp) but
-    // in other environments there can be a large number of different functions
-    // involved in async traps.
     virtual bool
     CallFrameAddressIsValid (lldb::addr_t cfa)
     {
-        // Make sure the stack call frame addresses are 8 byte aligned
-        if (cfa & (8ull - 1ull))
-            return false;   // Not 8 byte aligned
+        // Make sure the stack call frame addresses are 16 byte aligned
+        if (cfa & (16ull - 1ull))
+            return false;   // Not 16 byte aligned
         if (cfa == 0)
             return false;   // Zero is not a valid stack address
         return true;
index 286b1ef..c84aec1 100644 (file)
@@ -482,7 +482,7 @@ DynamicLoaderPOSIXDYLD::GetThreadLocalData (const lldb::ModuleSP module, const l
     Log *log(GetLogIfAnyCategoriesSet(LIBLLDB_LOG_DYNAMIC_LOADER));
     if (log)
         log->Printf("DynamicLoaderPOSIXDYLD::Performed TLS lookup: "
-                    "module=%s, link_map=0x%" PRIx64 ", tp=0x%" PRIx64 ", modid=%" PRId64 ", tls_block=0x%" PRIx64 "\n",
+                    "module=%s, link_map=0x%" PRIx64 ", tp=0x%" PRIx64 ", modid=%ld, tls_block=0x%" PRIx64 "\n",
                     mod->GetObjectName().AsCString(""), link_map, tp, (int64_t)modid, tls_block);
 
     return tls_block;