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

[Andre Przywara]

On Fri, 18 Aug 2023 14:17:07 -0700
Sam Edwards <cfsworks at gmail.com> wrote:

> 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.

      ^^^^^^^
Do you have an update on this? I will try to test it on an R40 ASAP.

Cheers,
Andre

> 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