Re: [sw-dev] GCC 8.x or 9.x for FreeBSD rv64imafdc ??

From: Dennis Clarke <>
Date: Tue, 26 Nov 2019 18:58:38 +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_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 
             to enable, add "vfs.zfs.prefetch_disable=0" to 
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
vesta# ls -lap usr/bin/clang
-r-xr-xr-x  3 root  wheel  63383544 Nov 26 08:00 usr/bin/clang
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: []
  0x0000000000000001 (NEEDED)             Shared library: []
  0x0000000000000001 (NEEDED)             Shared library: []
  0x0000000000000001 (NEEDED)             Shared library: []
  0x0000000000000001 (NEEDED)             Shared library: []
  0x0000000000000001 (NEEDED)             Shared library: []
  0x0000000000000001 (NEEDED)             Shared library: []
  0x0000000000000001 (NEEDED)             Shared library: []
  0x0000000000000001 (NEEDED)             Shared library: []
  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 in /lib :

vesta# ls -l lib/
-r--r--r--  1 root  wheel  94360 Nov 26 07:58 lib/

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 = 
     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
         .section        .rodata
         .align  3
         .string " the sizeof(pi128) is %i\n"
         .align  3
         .string " the sizeof(pi64) is %i\n"
         .align  3
         .string "pi128 may be %44.38Lg\n"
         .align  3
         .string "pi64 may be %44.38Lg\n"
         .align  1
         .globl  main
         .type   main, _at_function
         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
         .word   3306619320
         .word   2221509004
         .word   3041149649
         .word   1073779231
         .align  3
         .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
# echo "16o 1073779231p 3041149649p 2221509004p 3306619320pq"  | dc

I did file a bug :

     Bug 242067 - libc: r354823 riscv64 has a fault in printf()
                  where IEEE754-2008 fp128 data is output wrong

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
UNIX and Linux spoken
GreyBeard and suspenders optional

ps: currently locked in battle with this
Received 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