From: Ojaswin Mujoo <ojaswin@linux.ibm.com>
To: "Michael Ellerman" <mpe@ellerman.id.au>
Cc: linuxppc-dev@lists.ozlabs.org
Subject: [PATCH] powerpc: Fix a wrong version calculation issue in ld_version
Date: Tue, 3 Jan 2023 15:27:40 +0530 [thread overview]
Message-ID: <20230103095740.916038-1-ojaswin@linux.ibm.com> (raw)
** The Issue **
The ld_version() function seems to compute the wrong version value for
certain ld versions like the following:
$ ld --version GNU ld (GNU Binutils; SUSE Linux Enterprise 15)
2.37.20211103-150100.7.37
For input 2.37.20211103, the value computed is 202348030000 which is way
more the value for a higher version like 2.39.0, that is 23900000.
This issue was highlighted because with the above ld version, my powerpc
kernel build started failing with ld error: "unrecognized option
--no-warn-rwx-segments". This was caused due to the recent patch
579aee9fc594 added --no-warn-rwx-segments linker flag if the ld version
was greater than 2.39.
Due to the bug in ld_version(), my ld version (2.37.20111103) was
wrongly calculated to be greater than 2.39 and the unsupported flag was
added.
** The fix **
If version is of the form x.y.z and length(z) == 8, then most probably
it is a date [yyyymmdd]. As an approximation, discard the dd and yyyy
parts and keep the mm part in the version.
Signed-off-by: Ojaswin Mujoo <ojaswin@linux.ibm.com>
---
This is just an approximation since I'm not sure how common such release
versions for ld are and I didn't wan't to uneccassarily complicate the
logic. In case we want more accuracy we can try to use the last 4/5
digits to represent a more accurate date. Let me know if that would be
the preferred way.
PS: This issue also exists in ./scripts/ld-version.sh and I can look
into fixing that after this patch.
arch/powerpc/boot/wrapper | 4 ++++
1 file changed, 4 insertions(+)
diff --git a/arch/powerpc/boot/wrapper b/arch/powerpc/boot/wrapper
index af04cea82b94..af2688f79224 100755
--- a/arch/powerpc/boot/wrapper
+++ b/arch/powerpc/boot/wrapper
@@ -210,6 +210,10 @@ ld_version()
gsub(".*version ", "");
gsub("-.*", "");
split($1,a, ".");
+ if( length(a[3]) == "8" )
+ # a[3] is probably a date of format yyyymmdd. An 8 digit number will break
+ # the function so just keep the "mm" part as an approximation
+ a[3] = substr(a[3],5,2);
print a[1]*100000000 + a[2]*1000000 + a[3]*10000;
exit
}'
--
2.31.1
next reply other threads:[~2023-01-03 10:51 UTC|newest]
Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-01-03 9:57 Ojaswin Mujoo [this message]
[not found] <20230103095740.916038-1-ojaswin__39223.4750370093$1672743051$gmane$org@linux.ibm.com>
2023-01-03 15:32 ` [PATCH] powerpc: Fix a wrong version calculation issue in ld_version Andreas Schwab
2023-01-04 7:03 ` Ojaswin Mujoo
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=20230103095740.916038-1-ojaswin@linux.ibm.com \
--to=ojaswin@linux.ibm.com \
--cc=linuxppc-dev@lists.ozlabs.org \
--cc=mpe@ellerman.id.au \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.