linux-kernel - scripts/ld-version.sh doesn't work, breaking mips build with older toolchain.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Message-ID: <CAOS_Y6Sv6LjbswcQTpzULSzLmzx_FOXTLfB-pLRV+PZPNJ7mVQ@mail.gmail.com>
Date:	Mon, 22 Feb 2016 02:44:29 -0600
From:	Rob Landley <rob@...dley.net>
To:	Andi Kleen <ak@...ux.intel.com>,
	Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: scripts/ld-version.sh doesn't work, breaking mips build with older toolchain.

The 4.4 kernel no longer builds for me on mips, ala:

/tmp/ccXLGh3W.s: Assembler messages:
/tmp/ccXLGh3W.s:44: Error: can't resolve `_start' {*UND* section} -
`L0.' {.text section}
/tmp/ccXLGh3W.s:1217: Error: can't resolve `_start' {*UND* section} -
`L0.' {.text section}
make[2]: *** [arch/mips/vdso/gettimeofday.o] Error 1
make[1]: *** [arch/mips/vdso] Error 2

And the reason is:

$ ld --version scripts/ld-version.sh
GNU ld (GNU Binutils for Ubuntu) 2.22
...
$ ld --version | scripts/ld-version.sh
22200000
$ mips-ld --version
GNU ld (GNU Binutils) 2.17.50.20070703
...
$ mips-ld --version | scripts/ld-version.sh
2029270300

Well, the _other_ reason is that busybox awk complains the regex
doesn't compile due to an unmatched ")" but that's easy enough to fix:

diff --git a/scripts/ld-version.sh b/scripts/ld-version.sh
index 198580d..9ae1666 100755
--- a/scripts/ld-version.sh
+++ b/scripts/ld-version.sh
@@ -1,7 +1,7 @@
 #!/usr/bin/awk -f
 # extract linker version number from stdin and turn into single number
        {
-       gsub(".*)", "");
+       gsub(".*[)]", "");
        split($1,a, ".");
        print a[1]*10000000 + a[2]*100000 + a[3]*10000 + a[4]*100 + a[5];
        exit

And possibly the busybox guys are at fault for using ERE when they
should be using BRE, but once that's fixed the "longer number vs
larger number" issue crops up.

Rob