Re: GNU binutils 2.17.50 retirement planning
On 23/11/2018 11:23, Ed Maste wrote: > Retiring GNU as requires further investigation and effort as we have > some assembly files (for amd64 at least) which cannot be assembled by > Clang's integrated assembler. If Clang gains support for the required > functionality we'll switch to using IAS for all assembly files, and if > not we could rewrite the few assembly files to work with IAS. > I've been using the port binutils as for quite some time on amd64 (with WITHOUT_BINUTILS and WITHOUT_BINUTILS_BOOTSTRAP) with success by specifying XAS, although some Makefile logic in stand/i386/btx specify a hard-coded /usr/bin/as without bootstrapped binutils, necessitating a symlink. I temporarily re-enabled binutils bootstrap in trying to figure out the r339898 regression with retpoline, so things may have changed in light of r340681. If it is true that the only assembly files that clang IAS cannot assemble are for amd64 and i386, has there been any research into nasm and yasm at least? nasm is specified as a build dependency in certain multimedia/ ports, and yasm in gecko@, for amd64 and i386 assembly code. Both are licensed under some BSD licence variant. -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
Re: svn commit: r339898 - head/lib/libc/amd64/sys
On 05/11/2018 21:51, Konstantin Belousov wrote: > For you, but not for me. > Turns out I omitted the fact that I have WITH_RETPOLINE enabled, which caused all this. emaste@ reported in PR 26 and committed r340650. -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
svn commit: r339898 - head/lib/libc/amd64/sys
reason = step over frame #0: 0x002ebdad make`_fini at crtn.S:35 32 33 .section .fini,"ax",@progbits 34 addq$8,%rsp -> 35 ret 36 37 .section .note.GNU-stack,"",%progbits (lldb) n Process 22663 stopped * thread #1, name = 'make', stop reason = step over frame #0: 0x002ebdbc make -> 0x2ebdbc: jmp0x2ebd92 ; _init + 6 0x2ebdc1: pushq $0x0 0x2ebdc6: jmp0x2ebd80 ; __do_global_ctors_aux + 48 0x2ebdcb: int3 (lldb) n Process 22663 stopped * thread #1, name = 'make', stop reason = instruction step over frame #0: 0x002ebd92 make`_init + 6 make`_init: -> 0x2ebd92 <+6>: movsl (%rsi), %es:(%rdi) (lldb) n Process 22663 stopped * thread #1, name = 'make', stop reason = signal SIGSEGV: invalid address (fault address: 0x0) frame #0: 0x0000002ebd92 make`_init + 6 make`_init: -> 0x2ebd92 <+6>: movsl (%rsi), %es:(%rdi) (lldb) n Process 22663 exited with status = -1 (0x) (lldb) -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
Re: svn commit: r339898 - head/lib/libc/amd64/sys
On 03/11/2018 11:29, Konstantin Belousov wrote: > Some minimal amount of facts instead of guesses would be much more useful. > Yeah, being sleep deprived and hurried (on my end) certainly doesn't help. > What is the instruction which faulted ? Disassemble the text at 0x2f5664. > Regardless of what is the instruction, show either the output from > 'x86info -f' on the machine, or cpu identification lines from the > _verbose_ boot dmesg. > It appears that 0x2f5664 does not exist: Disassembly of section .init: 002f565c <_init>: 2f565c: 48 83 ec 08 sub$0x8,%rsp 2f5660: e8 fb 3c f3 ff callq 229360 2f5665: e8 b6 ff ff ff callq 2f5620 <__do_global_ctors_aux> 2f566a: 48 83 c4 08 add$0x8,%rsp 2f566e: c3 retq CPU ident: CPU: Intel(R) Core(TM) i7-5500U CPU @ 2.40GHz (2394.52-MHz K8-class CPU) Origin="GenuineIntel" Id=0x306d4 Family=0x6 Model=0x3d Stepping=4 Features=0xbfebfbff Features2=0x7ffafbbf AMD Features=0x2c100800 AMD Features2=0x121 Structured Extended Features=0x21c27ab Structured Extended Features3=0x9c00 XSAVE Features=0x1 VT-x: PAT,HLT,MTF,PAUSE,EPT,UG,VPID TSC: P-state invariant, performance statistics > make is statically linked, do dynamically linked program fault ? > After some more checks, only the statically linked programs crash. -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
Re: svn commit: r339898 - head/lib/libc/amd64/sys
On 01/11/2018 15:43, Charlie Li wrote: > On 01/11/2018 12:04, Brooks Davis wrote: >> Is this failure with devel/llvm70? It's currently missing the patch >> required to make this work. https://reviews.freebsd.org/D17709 contains >> this patch among others. I'll see about getting it applied. >> > Yes, devel/llvm70. Will build with your port commit at my next opportunity. > After building world and kernel r340097, kernel runs fine, but every userspace program in world crashes with Illegal instruction. They all crash in exactly the same way. Example backtrace from bmake, running from objdir (first discovered after updating a poudriere jail and attempting to even start it): Reading symbols from /usr/obj/usr/src/amd64.amd64/usr.bin/bmake/make...Reading symbols from /usr/obj/usr/src/amd64.amd64/usr.bin/bmake/make.debug...done. done. [New LWP 100097] Core was generated by `/usr/obj/usr/src/amd64.amd64/usr.bin/bmake/make --help'. Program terminated with signal SIGILL, Illegal instruction. #0 0x002f5664 in _init () (gdb) bt #0 0x002f5664 in _init () #1 0x002290fe in _start (ap=, cleanup=) at /usr/src/lib/csu/amd64/crt1.c:66 Given the line number referenced in crt1.c, I'm guessing this condition may have existed since at least r339351. -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
Re: svn commit: r339898 - head/lib/libc/amd64/sys
On 01/11/2018 12:04, Brooks Davis wrote: > Is this failure with devel/llvm70? It's currently missing the patch > required to make this work. https://reviews.freebsd.org/D17709 contains > this patch among others. I'll see about getting it applied. > Yes, devel/llvm70. Will build with your port commit at my next opportunity. -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
Re: svn commit: r339898 - head/lib/libc/amd64/sys
On 29/10/2018 20:11, Konstantin Belousov wrote: > Author: kib > Date: Tue Oct 30 00:11:30 2018 > New Revision: 339898 > URL: https://svnweb.freebsd.org/changeset/base/339898 > > Log: > Convert amd64_get/set_fs/gsbase to ifunc. > > Note that this is the first use of ifuncs in our userspace. > > Sponsored by: The FreeBSD Foundation > MFC after: 1 month > > Deleted: > head/lib/libc/amd64/sys/amd64_detect_rdfsgsbase.c > head/lib/libc/amd64/sys/amd64_detect_rdfsgsbase.h > Modified: > head/lib/libc/amd64/sys/Makefile.inc > head/lib/libc/amd64/sys/amd64_get_fsbase.c > head/lib/libc/amd64/sys/amd64_get_gsbase.c > head/lib/libc/amd64/sys/amd64_set_fsbase.c > head/lib/libc/amd64/sys/amd64_set_gsbase.c > Using LLVM 7 to build world, fails: --- amd64_get_fsbase.o --- /usr/src/lib/libc/amd64/sys/amd64_get_fsbase.c:60:1: error: ifunc resolver function must have no parameters --- amd64_get_gsbase.o --- /usr/src/lib/libc/amd64/sys/amd64_get_gsbase.c:60:1: error: ifunc resolver function must have no parameters DEFINE_UIFUNC(, int, amd64_get_gsbase, (void **), static) ^ /usr/local/obj/usr/src/amd64.amd64/tmp/usr/include/x86/ifunc.h:43:44: note: expanded from macro 'DEFINE_UIFUNC' --- amd64_get_fsbase.o --- DEFINE_UIFUNC(, int, amd64_get_fsbase, (void **), static) ^ /usr/local/obj/usr/src/amd64.amd64/tmp/usr/include/x86/ifunc.h:43:44: note: expanded from macro 'DEFINE_UIFUNC' --- amd64_get_gsbase.o --- qual ret_type name args __attribute__((ifunc(#name "_resolver"))); \ ^ --- amd64_get_fsbase.o --- qual ret_type name args __attribute__((ifunc(#name "_resolver"))); \ ^ 1 error generated. --- amd64_get_gsbase.o --- 1 error generated. *** [amd64_get_gsbase.o] Error code 1 make[4]: stopped in /usr/src/lib/libc CI appears green after this commit, so I'm inclined to pin this on yet another instance of LLVM 7 being stricter than LLVM 6. Backing out this revision allows the build to continue (successfully). -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
Re: unknown -z value: common-page-size=4096
On 29/09/2018 07:36, Dimitry Andric wrote: > You can apply this changeset from the clang700-import branch: > > https://svnweb.freebsd.org/changeset/base/337325 > Ah, I definitely missed this revision. I ended up working around the error by manually removing the offending bit from kern.pre.mk, which has the same effect of this changeset. > or just use the clang700-import branch wholesale. :-) > I would, but I also update and build head irregularly and prefer to build and run the newest code as they are committed. That, and I'm a bit lazy to run svn merge when I update :-) -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
unknown -z value: common-page-size=4096
I've switched to using devel/xtoolchain-llvm70 yesterday to build amd64 base starting with r338990, and among other issues, ld.lld70 refuses to link the kernel: Building /usr/local/obj/usr/local/src/amd64.amd64/sys/ARDMORE/kernel.full --- kernel.full --- linking kernel.full ld.lld: error: unknown -z value: common-page-size=4096 ld.lld: error: unknown -z value: ifunc-noplt *** [kernel.full] Error code 1 make[2]: stopped in /usr/local/obj/usr/local/src/amd64.amd64/sys/ARDMORE (ARDMORE is basically GENERIC-NODEBUG, not that it matters) The ifunc-noplt is a known issue, it obviously didn't make it upstream in time for LLVM 7.0.0, and thus we carry the feature downstream. The crux of this link error though, emaste@ quipped in PR 230604 that LLD prior to 7.0.0 accepted but ignored unknown options, but now at least 7.0.0 disallows unknown options entirely. Which brings up the -z common-page-size=4096: has LLD been ignoring this part the whole time, and is it of any meaningful use anymore (it seemed to mean something with bfd)? -- Charlie Li Can't think of a witty .sigline today… (This email address is for mailing list use only; replace local-part with vishwin for off-list communication) signature.asc Description: OpenPGP digital signature
