public inbox for u-boot@lists.denx.de
 help / color / mirror / Atom feed
From: Sam Edwards <cfsworks@gmail.com>
To: Andre Przywara <andre.przywara@arm.com>
Cc: u-boot@lists.denx.de, Jagan Teki <jagan@amarulasolutions.com>,
	Samuel Holland <samuel@sholland.org>,
	Jernej Skrabec <jernej.skrabec@gmail.com>,
	Icenowy Zheng <uwu@icenowy.me>,
	Maksim Kiselev <bigunclemax@gmail.com>
Subject: Re: [PATCH v2 1/5] sunxi: psci: clean away preprocessor macros
Date: Fri, 18 Aug 2023 14:17:07 -0700	[thread overview]
Message-ID: <00d8e7d3-15a0-20cc-90bd-7a2fbc1867e8@gmail.com> (raw)
In-Reply-To: <ba7bf86f-3f4d-036a-9531-72a97d741f91@gmail.com>

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

  reply	other threads:[~2023-08-18 21:17 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-16 17:34 [PATCH v2 0/5] Allwinner R528/T113s PSCI Sam Edwards
2023-08-16 17:34 ` [PATCH v2 1/5] sunxi: psci: clean away preprocessor macros Sam Edwards
2023-08-18 14:11   ` Andre Przywara
2023-08-18 17:40     ` Sam Edwards
2023-08-18 21:17       ` Sam Edwards [this message]
2023-09-27 16:34         ` Andre Przywara
2023-09-27 23:32           ` Sam Edwards
2023-08-16 17:34 ` [PATCH v2 2/5] sunxi: psci: refactor register access to separate functions Sam Edwards
2023-08-18 14:57   ` Andre Przywara
2023-08-18 17:32     ` Sam Edwards
2023-08-16 17:34 ` [PATCH v2 3/5] sunxi: psci: stop modeling register layout with C structs Sam Edwards
2023-08-16 17:34 ` [PATCH v2 4/5] sunxi: psci: implement PSCI on R528 Sam Edwards
2023-09-27 16:31   ` Andre Przywara
2023-09-28  0:01     ` Sam Edwards
2023-09-28  0:35       ` Andre Przywara
2023-08-16 17:34 ` [PATCH v2 5/5] HACK: sunxi: psci: be compatible with v1 of R528 patchset Sam Edwards
2023-09-27 16:32   ` Andre Przywara
2023-09-27 23:28     ` Sam Edwards
2023-09-28  0:35       ` Andre Przywara

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=00d8e7d3-15a0-20cc-90bd-7a2fbc1867e8@gmail.com \
    --to=cfsworks@gmail.com \
    --cc=andre.przywara@arm.com \
    --cc=bigunclemax@gmail.com \
    --cc=jagan@amarulasolutions.com \
    --cc=jernej.skrabec@gmail.com \
    --cc=samuel@sholland.org \
    --cc=u-boot@lists.denx.de \
    --cc=uwu@icenowy.me \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox