Potential fix for stack pad

[JackPriceBurns]

Going off what HeartPiece said on Discord:

I've got a hunch that the stack stuff was something to do with how they called print or error statements via a macro

I'm undecided on this, but it does seem plausible to me
Writing a random ("blah", arg1, arg2); changes codegen which would look weird on it's own, but if we assumed JAudio used to be a debug print defined like

#if defined(DEBUG)
#define JAUDIO_PRINT OSReport
#else
#define JAUDIO_PRINT
#endif

Then...

// This:
JAUDIO_PRINT("Some print %s", arg1);

// Would become when debug is not on:
("Some print %s", arg1);

I've just taken the function name and tagged on reasonable vars that could have been printed for debug (also to achieve the correct stack) not sure if it's possible to recover what the actual print strings would have been.
I wasn't able to apply this to everywhere there was stack padding, so there's possibly something else at play as well

used a combination of Sol and Fable to help with this

[decomp-dev]

Report for GPIJ01_02 (4de598e - c9e24f8)

No changes

Report for DPIJ01_PIKIDEMO (4de598e - c9e24f8)

No changes

Report for G98E01_PIKIDEMO (4de598e - c9e24f8)

No changes

Report for G98P01_PIKIDEMO (4de598e - c9e24f8)

No changes

Report for GPIP01_00 (4de598e - c9e24f8)

No changes

Report for GPIE01_01 (4de598e - c9e24f8)

No changes

Report for GPIJ01_01 (4de598e - c9e24f8)

No changes

Report for GPIE01_00 (4de598e - c9e24f8)

No changes

[intns]

This is really great work, well done!

Given how anal we are about keeping the code's original style and flavour - do you have any proof of this or is just a plausible explanation?

[JackPriceBurns]

@intns no proof unfortunately which is why I'm undecided. I couldn't find any other decomp projects that have done something similar..

[Minty-Meeo]

It has been known for a long time that New Play Control! Pikmin 1 has additional print statements in the JAudio library, but I don't believe it has been investigated very deeply yet. I'm kind of shocked this does the same thing as the address-of operator fix that we resorted to, but kind of don't like the at-a-glance implication that these are actual debugging messages being restored knowing that the real ones can likely be found on Wii.

[Minty-Meeo]

For example, the following code is able to match AuxBusInit from verysimple.c on New Play Control! Pikmin 1:

static void AuxBusInit()
{
	u32 i;
	s16* circularBufferBase;
	u32 alloc2Size;

	static FxlineConfig fx_config[] = {
		{ 1, 0x000A, 0x6000, 0x000B, 0x0000, 0x00000032, { 0x0000, 0x0000, 0x0000, 0x01F4, 0x03E8, 0x0FA0, 0x1B58, 0x1F40 } },
		{ 0, 0x0000, 0x0000, 0x0001, 0x6000, 0x00000000, { 0x0000, 0x0000, 0x0000, 0x01F4, 0x03E8, 0x0FA0, 0x1B58, 0x1F40 } },
		{ 2, 0x000A, 0x3FFF, 0x000B, 0x3FFF, 0x00000028, { 0x0000, 0x0078, 0x00FA, 0x01F4, 0x03E8, 0x0FA0, 0x0FA0, 0x0FA0 } },
		{ 0, 0x0000, 0x1000, 0x0001, 0x1000, 0x00000000, { 0x0000, 0x0000, 0x0000, 0x01F4, 0x03E8, 0x0FA0, 0x1B58, 0x1F40 } },
	};

	for (i = 0; i < 4; ++i) {
		alloc2Size         = fx_config[i].circularBufferSize * 0xa0; // TODO: What is 160 bytes large?
		circularBufferBase = (s16*)OSAlloc2(alloc2Size);
		if (!circularBufferBase) {
			OSReport("No... I cannot alloc FX buffer (%d bytes)\n", alloc2Size);
		} else {
			OSReport("I alloc FX buffer (%d bytes)\n", alloc2Size);
		}
		DFX_SetFxLine(i, circularBufferBase, &fx_config[i]);
	}
}

Backporting these changes to the GCN repository fixes both the REF_ variable as well as the STACK_PAD_VAR(2).

[Minty-Meeo]

To be honest I always kind of assumed they used Console_printf for these long-lost print statements, so it comes as a shock to me that the usual OSReport was used.

[JackPriceBurns]

I'll close this PR, recovering the actual OSReport's from New Play Control! is much nicer than guessing
I'd rather make a new PR than update this one when I get around to it (if someone doesn't do it first)