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
next prev parent 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