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_at_callisto:~ # root_at_callisto:~ # uname -apKU FreeBSD callisto 13.0-CURRENT FreeBSD 13.0-CURRENT r350568 QEMU riscv riscv64 1300038 1300038 root_at_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_at_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_at_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 <stdio.h> #include <stdlib.h> #include <math.h> 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, _at_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/lastmilesReceived on Tue Nov 26 2019 - 18:04:03 UTC
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:41:22 UTC