WITH_RETPOLINE kills init at boot (was:Re: r343917 fails into single-user mode at boot - new clang related issue?)
Quoting Mark Millard (from Sat, 9 Feb 2019 13:11:46 -0800): Alexander Leidinger Alexander at leidinger.net wrote on Removing the CPUTYPE setting in make.conf didn't help. Ideas welcome. I am running: # uname -apKU FreeBSD FBSDFSSD 13.0-CURRENT FreeBSD 13.0-CURRENT #9 r343884M: Thu Feb 7 19:22:33 PST 2019 markmi@FBSDFSSD:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-NODBG amd64 amd64 1300010 1300010 but I happen to have been booting the SSD via Hyper-V under Windows 10 Pro instead of directly in recent times. (Things are configured to allow booting from the BIOS as well.) Also: My builds are normally with non-debug kernels, the above included. I'm not seeing any problems with booting in my context. ... I'd not expect clang vintage to be the issue. It's WITH_RETPOLINE which kills init. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF pgpXKJrHZt7fK.pgp Description: Digitale PGP-Signatur
Re: r343917 fails into single-user mode at boot - new clang related issue?
Alexander Leidinger Alexander at leidinger.net wrote on Sat Feb 9 17:26:10 UTC 2019 : > Quoting Alexander Leidinger (from Sat, 09 > Feb 2019 13:44:25 +0100): > > > This is after deleting /usr/obj, and cleaning the ccache cache. All > > cases are with CPUTYPE=native (Intel Xeon E5620). > > > > I remember a commit of a new clang to head. Anything else in the > > area of influence for this? > > My next try is to compile without CPUTYPE=native to see if the new > > clang is doing something in this area which it didn't do before. Has > > anyone else seen a similar issue or has an idea what to look at next? > > Removing the CPUTYPE setting in make.conf didn't help. Ideas welcome. > I am running: # uname -apKU FreeBSD FBSDFSSD 13.0-CURRENT FreeBSD 13.0-CURRENT #9 r343884M: Thu Feb 7 19:22:33 PST 2019 markmi@FBSDFSSD:/usr/obj/amd64_clang/amd64.amd64/usr/src/amd64.amd64/sys/GENERIC-NODBG amd64 amd64 1300010 1300010 but I happen to have been booting the SSD via Hyper-V under Windows 10 Pro instead of directly in recent times. (Things are configured to allow booting from the BIOS as well.) Also: My builds are normally with non-debug kernels, the above included. I'm not seeing any problems with booting in my context. But I've been running various FreeBSD versions based on clang 7 for a while. Currently: # clang -v FreeBSD clang version 7.0.1 (tags/RELEASE_701/final 349250) (based on LLVM 7.0.1) Target: x86_64-unknown-freebsd13.0 Thread model: posix InstalledDir: /usr/bin I'd not expect clang vintage to be the issue. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: r343917 fails into single-user mode at boot - new clang related issue?
Quoting Alexander Leidinger (from Sat, 09 Feb 2019 13:44:25 +0100): This is after deleting /usr/obj, and cleaning the ccache cache. All cases are with CPUTYPE=native (Intel Xeon E5620). I remember a commit of a new clang to head. Anything else in the area of influence for this? My next try is to compile without CPUTYPE=native to see if the new clang is doing something in this area which it didn't do before. Has anyone else seen a similar issue or has an idea what to look at next? Removing the CPUTYPE setting in make.conf didn't help. Ideas welcome. Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF pgpBdIRxpVmzv.pgp Description: Digitale PGP-Signatur
r343917 fails into single-user mode at boot - new clang related issue?
Hi, I'm updating from r342714M to r343917M. At boot init fails directly and I get asked which shell I want. /bin/sh dies directly too and I get asked which shell I want again. With the r342714-BE booted and mounting the r343917-BE somewhere I can start the new sh on the old system without issues. If I compare the objdump -x output of init (oldnew): for the old one there is an invalid relocation type 37 reported, and for the new one there is at the end of objdump an additional relocation record for .got.plt. The rest of the difference is just different offsets and sizes. The file util doesn't report anything different for init. This is after deleting /usr/obj, and cleaning the ccache cache. All cases are with CPUTYPE=native (Intel Xeon E5620). I remember a commit of a new clang to head. Anything else in the area of influence for this? My next try is to compile without CPUTYPE=native to see if the new clang is doing something in this area which it didn't do before. Has anyone else seen a similar issue or has an idea what to look at next? Bye, Alexander. -- http://www.Leidinger.net alexan...@leidinger.net: PGP 0x8F31830F9F2772BF http://www.FreeBSD.orgnetch...@freebsd.org : PGP 0x8F31830F9F2772BF pgpLzXzmbryKF.pgp Description: Digitale PGP-Signatur
