PPC patch works only with A6 stack frames

[OS923]

I just wrote my first 68K extension which patches a PowerPC function with a PowerPC function (FrameOval). It crashes except if I turn "Generate A6 stack frames" on. How is that possible?

[Daniel]

Could you show us three things: the code that patches the new routine in, the UnviversalProcPtr structure used (or the MixedMode calls that generate it), and the start of the code that actually patches the routine.

Also, when does the crash occur? When you try to do the patch? When you attempt to use the new routine?

If you are getting the crash while invoking the code from 68k, perhaps the calling conventions require a stack frame.

If not, I have no clue what's up and the information I requested will probably be needed to solve the problem.

[OS923]

The crash happens when the INIT is loading (error 10). When I get the memory fragment, I get the address to 'main' in return. Then I execute 'main' which installs the patch.

[Daniel]

I have no clue what to make of that.

From what I know about calling conventions and the LINK instruction, it shouldn't matter what A6 is when a function is called. The value should be saved regardless of what it is. Looking through the Mixed Mode Manger docs seems to confirm that.

All the ways of messing this up I can think of wouldn't care about what type of stack frame is used.

Does it actually work when it doesn't crash?

I suppose the next things to do involve carefully looking at the actual assembly of the various components (with and without the A6 stack frames option) and frequent use of the debugger.

[OS923]

I found it. I made a routine descriptor for 'main' with the procinfo of the patch. How bizarre that it worked with A6 stack frames.

But now the FAT version crashes. It crashes with bus error 3 when it draws the first oval.

https://tinyurl.com/fatpatch20180810

[Daniel]

I know how it worked that way.

The return address would always be on top of the stack, regardless of how many arguments there are. Main would get the return address right, but it would mess up A7. This would totally mess up any function that depended on it. But, when using a frame pointer, the actual value of A7 doesn't matter most of the time. All stack values are performed using A6-relative accesses, rather than A7-relative ones. And when a function ends, the UNLK instruction restores the A6 and A7 to values stored relative to A6.

So A7 is messed up for the duration of the function that calls main, but it is not used for anything and is quickly restored  by UNLK as it returns.

As for the new problem, I am not sure (haven't looked at the code yet since my main 9.2.2 machine isn't on at the moment).

Bus error usually (always?) means invalid memory access. You got it to work the first time, so I think you have the code figured out. Things like more UPP madness and parameter order confusion come to mind.

[OS923]

Thus if the debug version of a 68K program works then the release version may crash.