how to link math library when building bare metal application with custom linker script

1

I am building a RISC-V cpu core, and i am trying to build some C code for it. I have some basic code compiling and linking the way i want and working just fine, for example this:

asm("li sp, 0x390");
asm("li s0, 0x390");
asm("li ra, 0");

int main(void){
        char *memptr = 0 ;
        int sum = 0;
        for(int i = 0; i < 8; i++)
                *(memptr + i) = i;
        for(int i = 0; i < 8; i++)
                       sum += *(memptr + i);
        *((int*)0xC) = sum;

        asm("lw x31, 0xc(x0)");


}

and compile/link with these commands:

riscv64-unknown-elf-gcc -nostartfiles -nostdlib -mno-relax -march=rv32i -mabi=ilp32 -c main.c
riscv64-unknown-elf-ld -nostartfiles -nostdlib -march=rv32i -melf32lriscv -o main -T link.ld main.o

my linker script is the following:

OUTPUT_ARCH( "riscv" )
ENTRY(main)

MEMORY
{
        progmem (rx) : ORIGIN = 0x10000000, LENGTH = 8K
        ram (!rx) : ORIGIN = 0x20000000, LENGTH = 64K
}

SECTIONS
{
        .text : {
                main.o(.text)
        } > progmem


        .data : {
                main.o(.rodata)
                main.o(.data)
                main.o(.sdata)
                main.o(.bss)
        } > ram
}

With this setup, i get the results i want no problem. I get my text section (which i put in the program memory), and i get the data section with all of the subsections put in there and load it straight into ram (it works for what im doing right now).

The problems begin when i try to use floating point addition:

asm("li sp, 0x390");
asm("li s0, 0x390");
asm("li ra, 0");

float a = 1.7;
float b = 0.7;

int main(void){
        int *memptr = (int*)0x8;
        float c = a - b;

}

trying to link after compilation results in this error:

riscv64-unknown-elf-ld -nostartfiles -march=rv32i -melf32lriscv -o main -T link.ld main.o
riscv64-unknown-elf-ld: main.o: in function `main':
main.c:(.text+0x3c): undefined reference to `__subsf3'

I can see in the assembly file (using gcc -S option) that there is an instruction call __subsf3, but there is no such label anywhere in the .text section. I believe i have to somehow link the math library for this to work, so i have tried adding #include "math.h", and then adding various flags to the ld command like "-lc", "-lgcc", "-lm", but it results in these errors:

riscv64-unknown-elf-ld: cannot find -lc
riscv64-unknown-elf-ld: cannot find -lgcc
riscv64-unknown-elf-ld: cannot find -lm

By trial and error i have managed to come up with this

riscv64-unknown-elf-gcc -nostartfiles -mno-relax -march=rv32i -mabi=ilp32 -Wl,-emain -lm main.c -o main

which almost does what i want, but does not use my link script. if i add -Wl,link.ld then it again doesnt work, giving out errors:

/usr/lib/gcc/riscv64-unknown-elf/9.1.0/../../../../riscv64-unknown-elf/bin/ld: main.o:(.sdata+0x0): multiple definition of `a'; /tmp/cc0LmWB4.o:(.sdata+0x0): first defined here
/usr/lib/gcc/riscv64-unknown-elf/9.1.0/../../../../riscv64-unknown-elf/bin/ld: main.o:(.sdata+0x4): multiple definition of `b'; /tmp/cc0LmWB4.o:(.sdata+0x4): first defined here
/usr/lib/gcc/riscv64-unknown-elf/9.1.0/../../../../riscv64-unknown-elf/bin/ld: main.o: in function `main':
main.c:(.text+0xc): multiple definition of `main'; /tmp/cc0LmWB4.o:main.c:(.text+0xc): first defined here
/usr/lib/gcc/riscv64-unknown-elf/9.1.0/../../../../riscv64-unknown-elf/bin/ld: error: no memory region specified for loadable section `.sdata'
collect2: error: ld returned 1 exit status

I would really appreciate if someone could explain me what im doing wrong, and how i should actually go about building the code using the floating point math above for bare metal RISC-V, and get ld to add the math functions in my .text section.

assembly
compilation
linker
riscv
bare-metal
asked on Stack Overflow Jul 13, 2019 by toby • edited Jul 13, 2019 by toby

1 Answer

3

The problem is that gcc is not a linker it is a compiler, but in the gnu world gcc knows where it is (from a directory and relative paths perspective). Ld is a linker but doesnt know where it is (typical use case (by design) it relies on gcc to pass the library path to it) so...

bootstrap.s

.globl _start
_start:
    lui x2,0x20010
    jal notmain
    j .

notmain.c

unsigned int abcd = 5;

float fun ( float a, float b)
{
    return(a+b);
}

int notmain ( void )
{
    return(0);
}

memmap

MEMORY
{
    rom : ORIGIN = 0x10000000, LENGTH = 8K
    ram : ORIGIN = 0x20000000, LENGTH = 64K
}

SECTIONS
{
    .text : { *(.text*) } > rom
    .rodata : { *(.rodata*) } > rom
    .bss : { *(.bss*) } > ram
    .data : { *(.data*) } > ram
}

One way:

riscv32-none-elf-as --warn -march=rv32i -mabi=ilp32 bootstrap.s -o bootstrap.o
riscv32-none-elf-gcc -Wall -march=rv32i -mabi=ilp32 -O2 -nostdlib -nostartfiles -ffreestanding  -c notmain.c -o notmain.o
riscv32-none-elf-ld -T memmap bootstrap.o notmain.o -lgcc -L /opt/gnuriscv32/lib/gcc/riscv32-none-elf/9.1.0/rv32i/ilp32 -o notmain.elf
riscv32-none-elf-objcopy notmain.elf -O binary notmain.bin 
riscv32-none-elf-objdump -D notmain.elf > notmain.list

gives

10000000 <_start>:
10000000:   20010137            lui x2,0x20010
10000004:   020000ef            jal x1,10000024 <notmain>
10000008:   0000006f            j   10000008 <_start+0x8>

1000000c <fun>:
1000000c:   ff010113            addi    x2,x2,-16 # 2000fff0 <abcd+0xfff0>
10000010:   00112623            sw  x1,12(x2)
10000014:   018000ef            jal x1,1000002c <__addsf3>
10000018:   00c12083            lw  x1,12(x2)
1000001c:   01010113            addi    x2,x2,16
10000020:   00008067            ret

10000024 <notmain>:
10000024:   00000513            li  x10,0
10000028:   00008067            ret

1000002c <__addsf3>:
1000002c:   008006b7            lui x13,0x800
10000030:   ff010113            addi    x2,x2,-16
10000034:   01755713            srli    x14,x10,0x17

...


20000000 <abcd>:
20000000:   0005
    ...

equally distasteful:

riscv32-none-elf-as --warn -march=rv32i -mabi=ilp32 bootstrap.s -o bootstrap.o
riscv32-none-elf-gcc -Wall -march=rv32i -mabi=ilp32 -O2 -nostdlib -nostartfiles -ffreestanding  -c notmain.c -o notmain.o
riscv32-none-elf-gcc -Wall -march=rv32i -mabi=ilp32 -O2 -nostdlib -nostartfiles -ffreestanding  -Xlinker -T -Xlinker memmap bootstrap.o notmain.o -lgcc -o notmain.elf
riscv32-none-elf-objcopy notmain.elf -O binary notmain.bin 
riscv32-none-elf-objdump -D notmain.elf > notmain.list

gives

10000000 <_start>:
10000000:   20010137            lui x2,0x20010
10000004:   020000ef            jal x1,10000024 <notmain>
10000008:   0000006f            j   10000008 <_start+0x8>

1000000c <fun>:
1000000c:   ff010113            addi    x2,x2,-16 # 2000fff0 <abcd+0xfff0>
10000010:   00112623            sw  x1,12(x2)
10000014:   018000ef            jal x1,1000002c <__addsf3>
10000018:   00c12083            lw  x1,12(x2)
1000001c:   01010113            addi    x2,x2,16
10000020:   00008067            ret

10000024 <notmain>:
10000024:   00000513            li  x10,0
10000028:   00008067            ret

1000002c <__addsf3>:
1000002c:   008006b7            lui x13,0x800
10000030:   ff010113            addi    x2,x2,-16

...


20000000 <abcd>:
20000000:   0005

the gcc solution is less painful as you dont have to hardcode a library path.

answered on Stack Overflow Jul 14, 2019 by old_timer

User contributions licensed under CC BY-SA 3.0