Enabling -shared in ELF embedded bare-metal toolchain

[Michael Clark]

Hi Jim,

I tried enabling -shared in the ELF toolchain and so far everything looks good. We get /lib/ld.so.1 as the canonical dynamic linker address, which is good, because it is the standard cross-platform ELF interpreter. When using the modified binutils, everything appears to work correctly. I see no difference between shared on the two ELF linkers.

Perhaps the problem is the Newlib build script?

which is kind or orthogonal to -shared with -nostartfiles -nostdlib -nostdinc -fPIC

It seems sad to disable relocatable objects in the ELF toolchain just because Newlib build script doesn't make shared objects. As far as I can tell the objects are exactly the same. This is unrelated to calling conventions or any

I have a test repo, but this disablement means I have to use the Linux toolchain when all I want is a baremetal toolchain that allows -shared in its binutils. It seems odd to disable a feature that is well defined. It's not like we are going to change the Embedded ELF tools to use something other than RELA for PT_DYNAMIC relocations is it? The GOT and PLT (and no PLT when using -static PIE) seems pretty well defined as far as I can tell. Of course FD-PIC would be a new ABI and this presumably would be added to both tuples so we could enable no-mmu Linux.

Anyway from my side, it appears to work when I remove the disablement. Of course I could be wrong and we might have plans to design an incompatible shared library ABI for the embedded binutils? Yes?

Michael.

Here is the test:

$ cat test.c 

int a;

int *b = &a;

void _start() {}

int hello() { return 42; }

$ riscv64-unknown-linux-gnu-gcc -Os -pie -nostdlib -mcmodel=medany -fPIC test.c -o test.so  > b.txt

$ riscv64-unknown-elf-gcc -Os -pie -nostdlib -mcmodel=medany -fPIC test.c -o test.so > a.txt

$ diff -u a.txt b.txt 

<empty>

I see one RELA entry for the pointer as expected. Nice! It's like a PIC object with some metadata of where our static pointers are.

Here is the reloc code with the REL loop removed as I presume RISC-V only emits RELA?:

- https://www.openwall.com/lists/musl/2012/05/24/1/2

#include <stddef.h>

#include <elf.h>

#include <limits.h>

#if SIZE_MAX == 0xffffffff

typedef Elf32_Phdr Phdr;

#else

typedef Elf64_Phdr Phdr;

#endif

void __static_pie_reloc(size_t *p)

{

size_t aux[16] = {0}, dyn[24] = {0}, *z;

for (; *p; p++);

for (p++; *p; p++);

for (p++; *p; p+=2) if (*p<16) aux[*p]=p[1];

if (!aux[AT_BASE]) aux[AT_BASE] = aux[AT_PHDR] & -4096;

for (p=(void *)aux[AT_PHDR]; *p; p=(void *)((char *)p+aux[AT_PHENT])) {

Phdr *ph = (void *)p;

if (ph->p_type == PT_DYNAMIC) {

p = (void *)(aux[AT_BASE] + ph->p_vaddr);

break;

}

}

for (; *p; p+=2) if (*p<24) dyn[*p]=p[1];

if (dyn[DT_RELA]) {

p = (void *)(aux[AT_BASE] + dyn[DT_RELA]);

z = (void *)((char *)p + dyn[DT_RELASZ]);

for (; p<z; p = (void *)((char *)p + dyn[DT_RELAENT]))

*(size_t *)(aux[AT_BASE] + p[0]) = aux[AT_BASE] + p[2];

}

}

Here is the patch to binutils:

mjc@miqi:~/src/sifive/riscv-gnu-toolchain/riscv-binutils$ git diff

diff --git a/ld/emulparams/elf32lriscv-defs.sh b/ld/emulparams/elf32lriscv-defs.sh

index 91015d44714d..40983cf1139c 100644

--- a/ld/emulparams/elf32lriscv-defs.sh

+++ b/ld/emulparams/elf32lriscv-defs.sh

@@ -16,15 +16,8 @@ if test `echo "$host" | sed -e s/64//` = `echo "$target" | sed -e s/64//`; then

   esac

 fi

 

-# Enable shared library support for everything except an embedded elf target.

-case "$target" in

-  riscv*-elf)

-    ;;

-  *)

-    GENERATE_SHLIB_SCRIPT=yes

-    GENERATE_PIE_SCRIPT=yes

-    ;;

-esac

+GENERATE_SHLIB_SCRIPT=yes

+GENERATE_PIE_SCRIPT=yes

 

 TEXT_START_ADDR=0x10000

 MAXPAGESIZE="CONSTANT (MAXPAGESIZE)"

Here is the readelf output from the test object:

mjc@miqi:~/src/sifive/riscv-disassembler$ riscv64-unknown-elf-readelf -a test.so 

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:                              DYN (Shared object file)

  Machine:                           RISC-V

  Version:                           0x1

  Entry point address:               0x1d0

  Start of program headers:          64 (bytes into file)

  Start of section headers:          1592 (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:         5

  Size of section headers:           64 (bytes)

  Number of section headers:         15

  Section header string table index: 14

Section Headers:

  [Nr] Name              Type             Address           Offset

       Size              EntSize          Flags  Link  Info  Align

  [ 0]                   NULL             0000000000000000  00000000

       0000000000000000  0000000000000000           0     0     0

  [ 1] .interp           PROGBITS         0000000000000158  00000158

       000000000000000d  0000000000000000   A       0     0     1

  [ 2] .hash             HASH             0000000000000168  00000168

       0000000000000014  0000000000000004   A       3     0     8

  [ 3] .dynsym           DYNSYM           0000000000000180  00000180

       0000000000000030  0000000000000018   A       4     2     8

  [ 4] .dynstr           STRTAB           00000000000001b0  000001b0

       0000000000000001  0000000000000000   A       0     0     1

  [ 5] .rela.dyn         RELA             00000000000001b8  000001b8

       0000000000000018  0000000000000018   A       3     0     8

  [ 6] .text             PROGBITS         00000000000001d0  000001d0

       0000000000000008  0000000000000000  AX       0     0     2

  [ 7] .dynamic          DYNAMIC          00000000000011d8  000001d8

       0000000000000100  0000000000000010  WA       4     0     8

  [ 8] .data             PROGBITS         00000000000012d8  000002d8

       0000000000000008  0000000000000000  WA       0     0     8

  [ 9] .got              PROGBITS         00000000000012e0  000002e0

       0000000000000008  0000000000000008  WA       0     0     8

  [10] .bss              NOBITS           00000000000012e8  000002e8

       0000000000000008  0000000000000000  WA       0     0     4

  [11] .comment          PROGBITS         0000000000000000  000002e8

       0000000000000011  0000000000000001  MS       0     0     1

  [12] .symtab           SYMTAB           0000000000000000  00000300

       0000000000000258  0000000000000018          13    17     8

  [13] .strtab           STRTAB           0000000000000000  00000558

       0000000000000073  0000000000000000           0     0     1

  [14] .shstrtab         STRTAB           0000000000000000  000005cb

       000000000000006b  0000000000000000           0     0     1

Key to Flags:

  W (write), A (alloc), X (execute), M (merge), S (strings), I (info),

  L (link order), O (extra OS processing required), G (group), T (TLS),

  C (compressed), x (unknown), o (OS specific), E (exclude),

  p (processor specific)

There are no section groups in this file.

Program Headers:

  Type           Offset             VirtAddr           PhysAddr

                 FileSiz            MemSiz              Flags  Align

  PHDR           0x0000000000000040 0x0000000000000040 0x0000000000000040

                 0x0000000000000118 0x0000000000000118  R      0x8

  INTERP         0x0000000000000158 0x0000000000000158 0x0000000000000158

                 0x000000000000000d 0x000000000000000d  R      0x1

      [Requesting program interpreter: /lib/ld.so.1]

  LOAD           0x0000000000000000 0x0000000000000000 0x0000000000000000

                 0x00000000000001d8 0x00000000000001d8  R E    0x1000

  LOAD           0x00000000000001d8 0x00000000000011d8 0x00000000000011d8

                 0x0000000000000110 0x0000000000000118  RW     0x1000

  DYNAMIC        0x00000000000001d8 0x00000000000011d8 0x00000000000011d8

                 0x0000000000000100 0x0000000000000100  RW     0x8

 Section to Segment mapping:

  Segment Sections...

   00     

   01     .interp 

   02     .interp .hash .dynsym .dynstr .rela.dyn .text 

   03     .dynamic .data .got .bss 

   04     .dynamic 

Dynamic section at offset 0x1d8 contains 12 entries:

  Tag        Type                         Name/Value

 0x0000000000000004 (HASH)               0x168

 0x0000000000000005 (STRTAB)             0x1b0

 0x0000000000000006 (SYMTAB)             0x180

 0x000000000000000a (STRSZ)              1 (bytes)

 0x000000000000000b (SYMENT)             24 (bytes)

 0x0000000000000015 (DEBUG)              0x0

 0x0000000000000007 (RELA)               0x1b8

 0x0000000000000008 (RELASZ)             24 (bytes)

 0x0000000000000009 (RELAENT)            24 (bytes)

 0x000000006ffffffb (FLAGS_1)            Flags: PIE

 0x000000006ffffff9 (RELACOUNT)          1

 0x0000000000000000 (NULL)               0x0

Relocation section '.rela.dyn' at offset 0x1b8 contains 1 entry:

  Offset          Info           Type           Sym. Value    Sym. Name + Addend

0000000012d8  000000000003 R_RISCV_RELATIVE                     12e8

The decoding of unwind sections for machine type RISC-V is not currently supported.

Symbol table '.dynsym' contains 2 entries:

   Num:    Value          Size Type    Bind   Vis      Ndx Name

     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 

     1: 00000000000001d0     0 SECTION LOCAL  DEFAULT    6 

Symbol table '.symtab' contains 25 entries:

   Num:    Value          Size Type    Bind   Vis      Ndx Name

     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 

     1: 0000000000000158     0 SECTION LOCAL  DEFAULT    1 

     2: 0000000000000168     0 SECTION LOCAL  DEFAULT    2 

     3: 0000000000000180     0 SECTION LOCAL  DEFAULT    3 

     4: 00000000000001b0     0 SECTION LOCAL  DEFAULT    4 

     5: 00000000000001b8     0 SECTION LOCAL  DEFAULT    5 

     6: 00000000000001d0     0 SECTION LOCAL  DEFAULT    6 

     7: 00000000000011d8     0 SECTION LOCAL  DEFAULT    7 

     8: 00000000000012d8     0 SECTION LOCAL  DEFAULT    8 

     9: 00000000000012e0     0 SECTION LOCAL  DEFAULT    9 

    10: 00000000000012e8     0 SECTION LOCAL  DEFAULT   10 

    11: 0000000000000000     0 SECTION LOCAL  DEFAULT   11 

    12: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS test.c

    13: 0000000000000000     0 FILE    LOCAL  DEFAULT  ABS 

    14: 00000000000011d8     0 OBJECT  LOCAL  DEFAULT  ABS _DYNAMIC

    15: 00000000000001d0     0 OBJECT  LOCAL  DEFAULT  ABS _PROCEDURE_LINKAGE_TABLE_

    16: 00000000000012e0     0 OBJECT  LOCAL  DEFAULT  ABS _GLOBAL_OFFSET_TABLE_

    17: 0000000000001ae8     0 NOTYPE  GLOBAL DEFAULT    9 __global_pointer$

    18: 00000000000012d8     8 OBJECT  GLOBAL DEFAULT    8 b

    19: 00000000000001d2     6 FUNC    GLOBAL DEFAULT    6 hello

    20: 00000000000001d0     2 FUNC    GLOBAL DEFAULT    6 _start

    21: 00000000000012e8     0 NOTYPE  GLOBAL DEFAULT   10 __bss_start

    22: 00000000000012e8     0 NOTYPE  GLOBAL DEFAULT    9 _edata

    23: 00000000000012f0     0 NOTYPE  GLOBAL DEFAULT   10 _end

    24: 00000000000012e8     4 OBJECT  GLOBAL DEFAULT   10 a

Histogram for bucket list length (total of 1 bucket):

 Length  Number     % of total  Coverage

      0  1          (100.0%)

No version information found in this file.

Here is the disassembly of the bare metal relocation code. Nice! Its only 180 bytes using -Os:

$ riscv64-unknown-elf-objdump -d a.o 

a.o:     file format elf64-littleriscv

Disassembly of section .text:

0000000000000000 <__static_pie_reloc>:

   0: 714d                addi sp,sp,-336

   2: e2a2                sd s0,320(sp)

   4: 08000613          li a2,128

   8: 4581                li a1,0

   a: 842a                mv s0,a0

   c: 850a                mv a0,sp

   e: e686                sd ra,328(sp)

  10: 00000097          auipc ra,0x0

  14: 000080e7          jalr ra # 10 <__static_pie_reloc+0x10>

  18: 0c000613          li a2,192

  1c: 4581                li a1,0

  1e: 0108                addi a0,sp,128

  20: 00000097          auipc ra,0x0

  24: 000080e7          jalr ra # 20 <__static_pie_reloc+0x20>

0000000000000028 <.L2>:

  28: 601c                ld a5,0(s0)

  2a: 0421                addi s0,s0,8

  2c: fff5                bnez a5,28 <.L2>

000000000000002e <.L3>:

  2e: 601c                ld a5,0(s0)

  30: 0421                addi s0,s0,8

  32: fff5                bnez a5,2e <.L3>

  34: 473d                li a4,15

0000000000000036 <.L4>:

  36: 601c                ld a5,0(s0)

  38: e3a9                bnez a5,7a <.L6>

  3a: 7762                ld a4,56(sp)

  3c: 67e2                ld a5,24(sp)

  3e: e701                bnez a4,46 <.L7>

  40: 777d                lui a4,0xfffff

  42: 8f7d                and a4,a4,a5

  44: fc3a                sd a4,56(sp)

0000000000000046 <.L7>:

  46: 7682                ld a3,32(sp)

  48: 4609                li a2,2

000000000000004a <.L8>:

  4a: 6398                ld a4,0(a5)

  4c: c719                beqz a4,5a <.L12>

  4e: 4398                lw a4,0(a5)

  50: 02c71f63          bne a4,a2,8e <.L9>

  54: 6b98                ld a4,16(a5)

  56: 77e2                ld a5,56(sp)

  58: 97ba                add a5,a5,a4

000000000000005a <.L12>:

  5a: 46dd                li a3,23

000000000000005c <.L10>:

  5c: 6398                ld a4,0(a5)

  5e: eb15                bnez a4,92 <.L14>

  60: 77ea                ld a5,184(sp)

  62: cb81                beqz a5,72 <.L1>

  64: 76e2                ld a3,56(sp)

  66: 670e                ld a4,192(sp)

  68: 652e                ld a0,200(sp)

  6a: 97b6                add a5,a5,a3

  6c: 973e                add a4,a4,a5

000000000000006e <.L16>:

  6e: 02e7ec63          bltu a5,a4,a6 <.L17>

0000000000000072 <.L1>:

  72: 60b6                ld ra,328(sp)

  74: 6416                ld s0,320(sp)

  76: 6171                addi sp,sp,336

  78: 8082                ret

000000000000007a <.L6>:

  7a: 00f76863          bltu a4,a5,8a <.L5>

  7e: 0294                addi a3,sp,320

  80: 078e                slli a5,a5,0x3

  82: 97b6                add a5,a5,a3

  84: 6414                ld a3,8(s0)

  86: ecd7b023          sd a3,-320(a5)

000000000000008a <.L5>:

  8a: 0441                addi s0,s0,16

  8c: b76d                j 36 <.L4>

000000000000008e <.L9>:

  8e: 97b6                add a5,a5,a3

  90: bf6d                j 4a <.L8>

0000000000000092 <.L14>:

  92: 00e6e863          bltu a3,a4,a2 <.L13>

  96: 0290                addi a2,sp,320

  98: 070e                slli a4,a4,0x3

  9a: 9732                add a4,a4,a2

  9c: 6790                ld a2,8(a5)

  9e: f4c73023          sd a2,-192(a4) # ffffffffffffef40 <.L17+0xffffffffffffee9a>

00000000000000a2 <.L13>:

  a2: 07c1                addi a5,a5,16

  a4: bf65                j 5c <.L10>

00000000000000a6 <.L17>:

  a6: 6390                ld a2,0(a5)

  a8: 6b8c                ld a1,16(a5)

  aa: 97aa                add a5,a5,a0

  ac: 9636                add a2,a2,a3

  ae: 95b6                add a1,a1,a3

  b0: e20c                sd a1,0(a2)

  b2: bf75                j 6e <.L16>

[Michael Clark]

Linux VDSO should be fine as long as we don't redefine "long" as all syscall arguments are cast to long in the syscall wrapper.

We should recompile it with both toolchains and compare, just to be sure. My guess is it should be fine, but of course, I could be wrong. I'm only about 85% sure (i am wrong?).

Anyway, we can blame Palmer if i'm not wrong 😀 He doesn't read his email so its safe,

[Jim Wilson]

On Wed, Sep 12, 2018 at 4:07 PM Michael Clark <m...@sifive.com> wrote:
> I tried enabling -shared in the ELF toolchain and so far everything looks good. We get /lib/ld.so.1 as the canonical dynamic linker address, which is good, because it is the standard cross-platform ELF interpreter. When using the modified binutils, everything appears to work correctly. I see no difference between shared on the two ELF linkers.

If you run the binutils testsuites with and without the patch, you
will see that you get more failures with the linker shared support
enabled. This is because the testsuites assume that if the linker has
shared support, then the entire toolchain has shared support, but this
isn't true because the newlib support is missing. The quality of the
binutils port is tracked by the number of failures we have, and
binutils maintainers are expected to show progress driving down the
number of failures. So having the embedded elf linker support enabled
makes us look bad. As an active binutils maintainer, this will cause
trouble for me.

You can run the binutils tests with "make check-binutils check-gas
check-ld". This requires the dejagnu package, which in turn requires
tcl and expect.

> Perhaps the problem is the Newlib build script?

Newlib by default does not provide shared library support. Most
embedded elf toolchains don't provide shared library support, as this
is difficult to do when you don't have any OS support to rely on.
Providing shared library support for an embedded target requires quite
a bit of working defining how they will work, and implementing the
necessary support for them. Some of the popular targets like arm-eabi
have done this, but in general it isn't done, and isn't expected to
work. But if someone did this work for RISC-V, then I would be
willing to re-enable the linker shared library support, as then it
would make sense to have it.

> I have a test repo, but this disablement means I have to use the Linux toolchain when all I want is a baremetal toolchain that allows -shared in its binutils. It seems odd to disable a feature that is well defined. It's not like we are going to change the Embedded ELF tools to use something other than RELA for PT_DYNAMIC relocations is it? The GOT and PLT (and no PLT when using -static PIE) seems pretty well defined as far as I can tell. Of course FD-PIC would be a new ABI and this presumably would be added to both tuples so we could enable no-mmu Linux.

This is a test repo to build a linux kernel yes? But a linux kernel
is linux code, and should be compiled by a linux compiler. I don't
know of anyone who uses an embedded elf compiler to build the linux
kernel other than some RISC-V folks, and this is a historical mistake.
Apparently, they decided to use an embedded elf compiler instead of a
linux compiler because it is easier to build a cross elf compiler than
a cross linux compiler. But an embedded elf compiler is not a drop in
replacement for a linux compiler. Even considering the fact that the
kernel doesn't use any library header files or library files, there
are still important differences between the elf and linux compilers.
wchar_t is different for instance, because wchar_t needs to match the
C library routines. The same is true of some other built-in types.
There are also some differences in default assembler/linker options.
Etc. Glibc will always be compiled by a linux compiler. We need to
ensure that all structure types shared by the kernel and glibc have
the same size and layout, and I can't guarantee that if one is
compiled by an embedded elf compiler and one is compiled by a linux
compiler. All linux distros will use a linux compiler of course. If
we test a kernel built by an embedded elf toolchain, then we aren't
testing the same thing that the linux distros are using. We have long
term plans to add a new embedded ABI, where the embedded toolchain
only uses 4 argument regs by default. This will break the linux
kernel unless you add extra options to use the linux ABI, and these
may or may not be options that the linux toolchain will accept.

From my point of view, if we want RISC-V to be a serious competitor,
with production quality tools, then we need to start doing things the
correct way, the way that upstream tools expect to be used, and are
willing to support. When RISC-V was an academic project, they could
afford to take short cuts, and use non-portable patches, because
things only needed to work well enough for the next demo, and it
didn't matter if non-RISC-V targets broke. Now that we have a number
of things fully merged with upstream, we need to meet a higher level
of standards. This means a few things have to change, and one of
things that has to change is that we have to stop using an embedded
elf compiler to build the linux kernel.

Jim

[Jim Wilson]

On Wed, Sep 12, 2018 at 4:14 PM Michael Clark <m...@sifive.com> wrote:

Linux VDSO should be fine as long as we don't redefine "long" as all syscall arguments are cast to long in the syscall wrapper.

We should recompile it with both toolchains and compare, just to be sure. My guess is it should be fine, but of course, I could be wrong. I'm only about 85% sure (i am wrong?).

It is just VDSOs today, but soon it will also be loadable kernel modules.  Any sensible person building a loadable kernel module will use a linux compiler.  What happens if the kernel was embedded elf compiled, but the loadable kernel module was linux compiled?  It isn't just the types of the arguments, but any other types that may be shared between the two, and in particular structure types.  Also the number of arguments, after the embedded elf toolchain eventually moves to the new ABI.  This is a problem that we shouldn't even be worrying about, as we just shouldn't allow building the kernel with the embedded elf toolchain in the first place.

Jim

[Michael Clark]

I agree with all of your concerns. We should not increase the number of test failures at this point.

That said, someone may choose to build a no-MMU FDPIC Linux kernel with the Embedded API registers some time in the future when we’ve decided whether or not we will use gp as the FDPIC register and whether FDPIC can be chosen independently of the ABI register set or whether it will be fixed to either the Linux or the EABI. Text and rodata for FDPIC will need to be PC-Relative (mcmodel=medany) so gp is essentially free to be used as the FDPIC register. We should not rule that option out. In any case FDPIC is not a top priority so we don’t have to worry too much about that. I still don’t have my FSF assignment done so I can’t work on that anyway. GP as the FDPIC register for FDPIC format lets us use either the Linux or EABI as it requires mcmodel=medany so can use any ABI. Indeed there is FDPIC Linux and FDPIC VxWorks so it’s flexible.

We can work on a more complete patch to enable shared in the Embedded Newlib toolchain; without adding regressions, once I’ve done my FSF assignment. I will use the Linux toolchain until then, or until someone beats me to it 😎 the Linux toolchain works for my purposes. It’s just that currently all the features I am using work equally well with either compiler.

I have another repo that I will share with you when I am ready (a Bare Metal Compiler Bundled Library neutral test case) that should be able to build with any of the RISC-V ABIs as that is one of the incorporating requirements of the test library. It could potentially even be built with the RISC-V FDPIC ABI (when this is defined by the community) and indeed potentially even a PE/COFF for a RISC-V UEFI implementation, it we write a test what uses gnu-efi on RISC-V. i.e. the PE/COFF RISC-V calling convention.

At this point, I just need to add a feature test for -shared which means I need to use the Linux Glibc compiler in the meantime for the static PIE test I am working on. static PIE uses a -shared like ABI with a GOT (RELA PT_DYNAMIC) but no PLTs as the executable functions are all resolved internally. Anyway you know how all of this works.

The tests I am working on at present are using -nostartfile -nostdlb -nostdinc -static and I believe (but will double check) the output is the same with both toolchains. We won’t be using wchar_t as we only need ASCII or UTF-8 for these particular tests 🤔 and there is no floating point in them yet.

Thanks,
Michael

[Michael Clark]

Sorry for top posting.

Indeed many distros use a dedicated “linux-kernel” compiler which is separate from the Glibc compiler. It’s often an older version of GCC than the Glibc compiler as Linus sometimes disagrees with the GCC developers like when they start doing clever optimisations like eliding NULL pointer tests hence Linux now compiles with flags such as -fno-delete-null-pointer-checks

https://lwn.net/Articles/342420/

The kernel compiler does need to agree on sizeof(long) and several other things however the calling convention can be thunked in entry.S because on some architectures e.g x86 the kernel can talk either i386 or x86_64 to userspace and userspace has assembly wrappers that are explicit about the argument registers. Often the kernel uses char for the float types to reserve enough space for them, and doesn’t use the types themselves. Some architectures may have assembly to save and restore the floating point register files, so it agnostic to that part of the ABI including wchar_t.

We could potentially do this type of thing for riscv64. e.g. support sstatus.uxl = rv32 processes that run riscv32 processes on 64-bit RISC-V kernels... It’s in the Privileged Spec. It’s just not there in software land... yet.

On 14/09/2018, at 12:53 PM, Jim Wilson <ji...@sifive.com> wrote:

--
You received this message because you are subscribed to the Google Groups "RISC-V SW Dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to sw-dev+un...@groups.riscv.org.
To post to this group, send email to sw-...@groups.riscv.org.
Visit this group at https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/CAFyWVab5A%3DKLS_FJPjQYL25Bq2dx-oFsakdMN9%2Bt1YMMeV2y3A%40mail.gmail.com.