[PATCH v2 1/5] sunxi: psci: clean away preprocessor macros

[Sam Edwards]

On 8/18/23 10:40, Sam Edwards wrote:
> On 8/18/23 07:11, Andre Przywara wrote:
> 
> Hi Andre,
> 
>> The resulting object file is different (8 byte larger,
>> even), so it's hard to prove
> 
> I'm no stranger to reading object code. Since the output should be 
> identical in principle, I'll spend a little bit of time today seeing if 
> I can identify what's changing. If it's easy enough, I'd like to adjust 
> my patch so that the optimizer does produce the same output. (Keep in 
> mind I'm on Clang, though. If Clang already gives the same output for 
> both, I'll just report back to use that when comparing.)

I built only psci.o from every ARM32 sunxi for which we have a defconfig 
(and for which PSCI is supported), for 81 targets total (though there 
are only 4 variations: R40, sun7i, H3/sun6i, and "everything else"). I 
am working with Clang version 16.0.6.

I compared only the secure text section. The command to extract this 
looks like:
llvm-objcopy -O binary --only-section=._secure.text psci.o text.bin
This is important because there are debug sections that will change when 
the source file line numbers change, so we must ignore those when comparing.

In the majority of cases, there are no changes to the text section 
introduced by this patch. In the R40 case, there's a small change where 
the compiler adds a NULL check onto the result of the `(void *)cpucfg + 
SUN8I_R40_PWR_CLAMP(cpu)` computation, which we can ignore as it won't 
affect anything in practice. In the sun7i case, the only changes are 
because I am NOT hardcoding the CPU to 0, which does look like I broke 
it (since that means it will use cpu=1). So I'm going to need to fix 
that in v3.

For good measure, I also applied the same methodology to patch 2 in this 
series, and that introduces no text section changes whatsoever in any of 
the tested cases. So patch 2 (theoretically, anyway) needs no bugfixes 
or hardware testing.

Patch 3 does cause a text section change for all targets. I will have to 
investigate why, in case I messed up any of the offsets when migrating 
off of structs.

Regards,
Sam