linuxppc-dev.lists.ozlabs.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] powerpc: Fix a wrong version calculation issue in ld_version
@ 2023-01-03  9:57 Ojaswin Mujoo
  0 siblings, 0 replies; 3+ messages in thread
From: Ojaswin Mujoo @ 2023-01-03  9:57 UTC (permalink / raw)
  To: Michael Ellerman; +Cc: linuxppc-dev

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


^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH] powerpc: Fix a wrong version calculation issue in ld_version
       [not found] <20230103095740.916038-1-ojaswin__39223.4750370093$1672743051$gmane$org@linux.ibm.com>
@ 2023-01-03 15:32 ` Andreas Schwab
  2023-01-04  7:03   ` Ojaswin Mujoo
  0 siblings, 1 reply; 3+ messages in thread
From: Andreas Schwab @ 2023-01-03 15:32 UTC (permalink / raw)
  To: Ojaswin Mujoo; +Cc: linuxppc-dev

On Jan 03 2023, Ojaswin Mujoo wrote:

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

I don't think any part of the date should be mixed into the computed
version.  It just means that it's a snapshot from after the 2.37
release, so it should be treated like 2.37 (no further releases has been
made from this branch).

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
"And now for something completely different."

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH] powerpc: Fix a wrong version calculation issue in ld_version
  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
  0 siblings, 0 replies; 3+ messages in thread
From: Ojaswin Mujoo @ 2023-01-04  7:03 UTC (permalink / raw)
  To: Andreas Schwab; +Cc: linuxppc-dev

On Tue, Jan 03, 2023 at 04:32:18PM +0100, Andreas Schwab wrote:
> On Jan 03 2023, Ojaswin Mujoo wrote:
> 
> > 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.
> 
> I don't think any part of the date should be mixed into the computed
> version.  It just means that it's a snapshot from after the 2.37
> release, so it should be treated like 2.37 (no further releases has been
> made from this branch).
> 
I see, in that case I agree that we can strip out the date part and
treat it as x.y.0. 

I'll wait a bit to see if there are any other comments and then send out
a v2.

Thanks,
ojaswin
> -- 
> Andreas Schwab, schwab@linux-m68k.org
> GPG Key fingerprint = 7578 EB47 D4E5 4D69 2510  2552 DF73 E780 A9DA AEC1
> "And now for something completely different."

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2023-01-04  7:04 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
     [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
2023-01-03  9:57 Ojaswin Mujoo

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).