I'm trying to knit together a legacy Codewarrior CFM application with 
XCode Mach-o dll. I've used the approach described by mac support and on 
various forums. The approach described uses:

UInt32 gluetab[6] = {0x3D800000, 0x618C0000, 0x800C0000, 0x804C0004, 
0x7C0903A6, 0x4E800420};

static void	*MachOPtrVoid (void *cfmfp)
{
     UInt32	*mfp = (UInt32*) NewPtr( sizeof(gluetab));		// Must later 
dispose of allocated memory
     mfp[0] = gluetab[0] | ((UInt32)cfmfp >> 16);
     mfp[1] = gluetab[1] | ((UInt32)cfmfp & 0xFFFF);
     mfp[2] = gluetab[2];
     mfp[3] = gluetab[3];
     mfp[4] = gluetab[4];
     mfp[5] = gluetab[5];
     MakeDataExecutable (mfp, sizeof(gluetab));
     return( mfp );
}

I'm trying to avoid the heap allocation, and to use a more encapsulated 
approach such as:

struct MachOFunctionPointer
{
   MachOFunctionPointer(void* cfmProcPtr)
   : m0(0x3D800000 | ((UInt32)cfmProcPtr >>    16))
   , m1(0x618C0000 | ((UInt32)cfmProcPtr & 0xFFFF))
   , m2(0x800C0000)
   , m3(0x804C0004)
   , m4(0x7C0903A6)
   , m5(0x4E800420)
   {
     MakeDataExecutable(this, sizeof(this));
   }
	
   UInt32 m0;
   UInt32 m1;
   UInt32 m2;
   UInt32 m3;
   UInt32 m4;
   UInt32 m5;
};

constructing an instance on the stack:

MachOFunctionPointer moFncPtr(some_cfm_fnc);

This leads to spurious crashes of the legacy codewarrior app, which I 
can't debug because the code warrior debugger won't run on mac intel 
machines.

If I pad the above struct at the end to 32 bytes, there are no crashes. 
I'm conjecturing that when allocating the former array, that the 
allocator is actually allocating to the next power-of-2 size which is 32 
bytes. I've tried using CodeWarrior #pragmas to set alignment and 
packing, but this doesn't seem to fix the problem.

Any thoughts on this topic are appreciated.

Thanks, Jeff