From owner-freebsd-current@freebsd.org Tue Nov 26 19:04:03 2019 Return-Path: Delivered-To: freebsd-current@mailman.nyi.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.nyi.freebsd.org (Postfix) with ESMTP id 775F61BED40 for ; Tue, 26 Nov 2019 19:04:03 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from jax4mhfb01.myregisteredsite.com (jax4mhfb01.myregisteredsite.com [64.69.218.94]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 47Mtc15701z490J for ; Tue, 26 Nov 2019 19:04:00 +0000 (UTC) (envelope-from dclarke@blastwave.org) Received: from jax4mhob05.myregisteredsite.com (jax4mhob05.myregisteredsite.com [64.69.218.85]) by jax4mhfb01.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id xAQIwitD009090 for ; Tue, 26 Nov 2019 13:58:45 -0500 Received: from mailpod.hostingplatform.com (atl4qobmail01pod2.registeredsite.com [10.30.77.35]) by jax4mhob05.myregisteredsite.com (8.14.4/8.14.4) with ESMTP id xAQIwd23014400 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL) for ; Tue, 26 Nov 2019 13:58:39 -0500 Received: (qmail 5410 invoked by uid 0); 26 Nov 2019 18:58:39 -0000 X-TCPREMOTEIP: 99.253.169.68 X-Authenticated-UID: dclarke@blastwave.org Received: from unknown (HELO ?172.16.35.2?) (dclarke@blastwave.org@99.253.169.68) by 0 with ESMTPA; 26 Nov 2019 18:58:39 -0000 Subject: Re: [sw-dev] GCC 8.x or 9.x for FreeBSD rv64imafdc ?? To: sw-dev@groups.riscv.org, FreeBSD CURRENT References: <5bca6745-1c09-3ba7-3b4a-2456ea2e1081@blastwave.org> From: Dennis Clarke Cc: Ruslan Bukin Message-ID: <1d824d98-dc81-706c-9741-41f363b81323@blastwave.org> Date: Tue, 26 Nov 2019 18:58:38 +0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:71.0) Gecko/20100101 Thunderbird/71.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 47Mtc15701z490J X-Spamd-Bar: ++++++ Authentication-Results: mx1.freebsd.org; dkim=none; dmarc=none; spf=none (mx1.freebsd.org: domain of dclarke@blastwave.org has no SPF policy when checking 64.69.218.94) smtp.mailfrom=dclarke@blastwave.org X-Spamd-Result: default: False [6.39 / 15.00]; ARC_NA(0.00)[]; RCVD_VIA_SMTP_AUTH(0.00)[]; GREYLIST(0.00)[pass,body]; FROM_HAS_DN(0.00)[]; RCPT_COUNT_THREE(0.00)[3]; TO_DN_SOME(0.00)[]; IP_SCORE(0.49)[ipnet: 64.69.218.0/23(0.84), asn: 19871(1.67), country: US(-0.05)]; MIME_GOOD(-0.10)[text/plain]; PREVIOUSLY_DELIVERED(0.00)[freebsd-current@freebsd.org]; DMARC_NA(0.00)[blastwave.org]; RBL_MAILSPIKE_WORST(2.00)[94.218.69.64.rep.mailspike.net : 127.0.0.10]; NEURAL_SPAM_MEDIUM(1.00)[1.000,0]; AUTH_NA(1.00)[]; RCVD_COUNT_THREE(0.00)[4]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; NEURAL_SPAM_LONG(1.00)[0.999,0]; RCVD_IN_DNSWL_NONE(0.00)[94.218.69.64.list.dnswl.org : 127.0.5.0]; R_SPF_NA(0.00)[]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; SUBJECT_ENDS_QUESTION(1.00)[]; ASN(0.00)[asn:19871, ipnet:64.69.218.0/23, country:US]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_TLS_LAST(0.00)[] X-Spam: Yes X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 26 Nov 2019 19:04:03 -0000 On 11/26/19 10:18 AM, Bruce Hoult wrote: > I think there are very few people who have experience with the > intersection of FreeBSD and RISC-V. > [warning] long rambling reply full of enthusiasm and hand waving :) Thank you for the reply and yes ! There are very few but it works I tell you it really does work and that is with a ZFS zpool. At least on QEMU for the moment and by Christmas time on the SiFive board. Maybe. Sort of waiting for a new board to pop up with SAS/SATA ports and more memory but Christmas may be here first. I simply can not go forwards with ZFS without memory and lots of it : root@callisto:~ # root@callisto:~ # uname -apKU FreeBSD callisto 13.0-CURRENT FreeBSD 13.0-CURRENT r350568 QEMU riscv riscv64 1300038 1300038 root@callisto:~ # zpool list ZFS NOTICE: Prefetch is disabled by default if less than 4GB of RAM is present; to enable, add "vfs.zfs.prefetch_disable=0" to /boot/loader.conf. ZFS filesystem version: 5 ZFS storage pool version: features support (5000) no pools available root@callisto:~ # > Hopefully Ruslan will reply. > Yes I have a compiler tarball from him that sort of works. When I say "sort of" I mean that I can compile some simple things and everything seems to work however I need to carefully specify where to find libgcc and even libc as there are some oddball paths stuck in his bootstrap result. Easy to work around. May even be enough to get a new bootstrap going of gcc 9.2.0 but I have not been able to get past libgmp. Yet. Maybe later today. Maybe tomorrow. :-\ For now I have been messing with r350568 with ZFS and a gcc from Ruslan but for anything after that I have nothing. I just drag around a tarball and hope for the best. However today I hear that I am slightly blind and that clang does exist in the rootfs : vesta# pwd /opt/rv64/rootfs vesta# ls -lap usr/bin/clang -r-xr-xr-x 3 root wheel 63383544 Nov 26 08:00 usr/bin/clang vesta# vesta# readelf -delV usr/bin/clang ELF Header: Magic: 7f 45 4c 46 02 01 01 00 00 00 00 00 00 00 00 00 Class: ELF64 Data: 2's complement, little endian Version: 1 (current) OS/ABI: UNIX - System V ABI Version: 0 Type: EXEC (Executable file) Machine: RISC-V Version: 0x1 Entry point address: 0x6d48a Start of program headers: 64 (bytes into file) Start of section headers: 63381560 (bytes into file) Flags: 0x5, RVC, double-float ABI Size of this header: 64 (bytes) Size of program headers: 56 (bytes) Number of program headers: 8 Size of section headers: 64 (bytes) Number of section headers: 31 Section header string table index: 30 Section Headers: . . . Dynamic section at offset 0x3c5ac08 contains 30 entries: Tag Type Name/Value 0x0000000000000001 (NEEDED) Shared library: [libz.so.6] 0x0000000000000001 (NEEDED) Shared library: [libexecinfo.so.1] 0x0000000000000001 (NEEDED) Shared library: [libncursesw.so.8] 0x0000000000000001 (NEEDED) Shared library: [libthr.so.3] 0x0000000000000001 (NEEDED) Shared library: [libc++.so.1] 0x0000000000000001 (NEEDED) Shared library: [libcxxrt.so.1] 0x0000000000000001 (NEEDED) Shared library: [libm.so.5] 0x0000000000000001 (NEEDED) Shared library: [libgcc_s.so.1] 0x0000000000000001 (NEEDED) Shared library: [libc.so.7] 0x000000000000000c (INIT) 0x16d40 0x000000000000000d (FINI) 0x2b7d086 0x0000000000000019 (INIT_ARRAY) 0x3c6b038 0x000000000000001b (INIT_ARRAYSZ) 2976 (bytes) . . . Not too sure how that is going to work with no RUNPATH or RPATH and it needs libgcc. However looking I do see libgcc_s.so.1 in /lib : vesta# ls -l lib/libgcc_s.so.1 -r--r--r-- 1 root wheel 94360 Nov 26 07:58 lib/libgcc_s.so.1 vesta# So this may actually work and be enough to bootstrap with. Maybe. > I see the gcc in that project is pretty old, 6.1.0. I have no idea > whether it would be easier to get 6.1.0 running natively inside > freebsd-riscv and then use it to build a newer gcc, or maybe enough > RISC-V improvements have been made to gcc in the last four years and > 16856 commits that it's better to rebase Ruslan's changes to current > gcc first. Well actually I do have 8.x of some flavour and only from Ruslan. > Maybe Ruslan has a native compiler working. Or maybe not. > > I'm sorry I can't be more helpful but at least it's not a black hole. Not a black hole is a damn fine thing !! Better than I expected in fact. In truth I just need some tools to get off the ground and maybe figure out how pi became pretty much 2.000 thus : root@callisto:/home/dclarke/foo # cat pi.c /************************************************* * The Open Group Base Specifications Issue 6 * IEEE Std 1003.1, 2004 Edition *************************************************/ #define _XOPEN_SOURCE 600 #include #include #include int main ( int argc, char *argv[]) { long double pi128 = 3.1415926535897932384626433832795028841971693993751L; double pi64 = M_PI; printf (" the sizeof(pi128) is %i\n", sizeof(pi128) ); printf (" the sizeof(pi64) is %i\n", sizeof(pi64) ); printf ("pi128 may be %44.38Lg\n", pi128 ); printf ("pi64 may be %18.16g\n", pi64 ); return ( EXIT_SUCCESS ); } The assembly looks perfect as does the static data : # cat pi.s .file "pi.c" .option nopic .text .section .rodata .align 3 .LC2: .string " the sizeof(pi128) is %i\n" .align 3 .LC3: .string " the sizeof(pi64) is %i\n" .align 3 .LC4: .string "pi128 may be %44.38Lg\n" .align 3 .LC5: .string "pi64 may be %44.38Lg\n" .text .align 1 .globl main .type main, @function main: addi sp,sp,-64 sd ra,56(sp) sd s0,48(sp) addi s0,sp,64 mv a5,a0 sd a1,-64(s0) sw a5,-52(s0) lui a5,%hi(.LC0) ld a4,%lo(.LC0)(a5) sd a4,-32(s0) ld a5,%lo(.LC0+8)(a5) sd a5,-24(s0) lui a5,%hi(.LC1) fld fa5,%lo(.LC1)(a5) fsd fa5,-40(s0) li a1,16 lui a5,%hi(.LC2) addi a0,a5,%lo(.LC2) call printf li a1,8 lui a5,%hi(.LC3) addi a0,a5,%lo(.LC3) call printf ld a2,-32(s0) ld a3,-24(s0) lui a5,%hi(.LC4) addi a0,a5,%lo(.LC4) call printf ld a1,-40(s0) lui a5,%hi(.LC5) addi a0,a5,%lo(.LC5) call printf li a5,0 mv a0,a5 ld ra,56(sp) ld s0,48(sp) addi sp,sp,64 jr ra .size main, .-main .section .rodata .align 4 .LC0: .word 3306619320 .word 2221509004 .word 3041149649 .word 1073779231 .align 3 .LC1: .word 1413754136 .word 1074340347 .ident "GCC: (GNU) 8.2.0" However the output is weird : # ./pi the sizeof(pi128) is 16 the sizeof(pi64) is 8 pi128 may be 2.0000076293945362811600603241536472604 pi64 may be 3.141592653589793 However the in memory data is flawless : # echo "16o 1074340347p 1413754136pq" | dc 400921FB 54442D18 # echo "16o 1073779231p 3041149649p 2221509004p 3306619320pq" | dc 4000921F B54442D1 8469898C C51701B8 I did file a bug : Bug 242067 - libc: r354823 riscv64 has a fault in printf() where IEEE754-2008 fp128 data is output wrong https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=242067 Which seems to happen down inside _ldtoa.c under gdtoa.c and I did single step all the way through the process on IBM PowerPC64 FreeBSD as well as amd64. Very weird output. -- Dennis Clarke RISC-V/SPARC/PPC/ARM/CISC UNIX and Linux spoken GreyBeard and suspenders optional ps: currently locked in battle with this https://www.twitch.tv/lastmiles