Is environment call "sbrk" supported on Ripes?

[asahsieh]

Hi,

I'm auditing a Computer Architecture course and Ripes is used for our homework. one of homework is to write a RISC-V assembly program based on a given C program and a C library function, malloc(), is used in this program.

I found an issue #34, dear author @mortbopet mentioned "the use of a0 for environment calls is to match what venus does". So I checked environment calls defined in venus, and found sbrk environment call are supported. I coded malloc() in assembly by giving ID(a0) = 9 and run Ripes, an error "Unknown system call in register 'a7': 9 Refer to "Help->System calls" for a list of support system calls." was pop up.

Is there any suggestion to implement malloc() on assembly code and run it on Ripes? Or I could try to porting sbrk syscall to Ripes?

Thanks in advance!

[mortbopet]

Hi @asahsieh
Thank you for using Ripes!
Venus' use of sbrk as ecall code 9 is a bit unconventional and (as far as i am aware of) Venus is the only simulator that actually does this. As mentioned in the issue, Ripes/RARS/... follow the riscv-proxy kernel ABI (as does the GCC toolchain) for system calls (https://github.com/riscv-software-src/riscv-pk/blob/master/pk/syscall.h).

Is there any suggestion to implement malloc() on assembly code and run it on Ripes?

The brk syscall is implemented in Ripes here. This is what is used by the C standard library to implement malloc

As such, if you have registered a compiler in Ripes and compile a simple program such as the following:

#include <stdlib.h>
volatile int* a;
int main() {
    a = malloc(5);
    return 0;
}

you'll see that the C standard library code which is linked into the executable will use brk (a7=214) in its sbrk implementation. The following is a snippet from that:

00011338 <_sbrk>:
    11338:        05018313        addi x6 x3 80
    1133c:        00032783        lw x15 0 x6
    11340:        ff010113        addi x2 x2 -16
    11344:        00112623        sw x1 12 x2
    11348:        00050813        addi x16 x10 0
    1134c:        02079863        bne x15 x0 48
    11350:        00000513        addi x10 x0 0
    11354:        00000593        addi x11 x0 0
    11358:        00000613        addi x12 x0 0
    1135c:        00000693        addi x13 x0 0
    11360:        00000713        addi x14 x0 0
    11364:        0d600893        addi x17 x0 214
    11368:        00000073        ecall
    ....

One caveat though; the implementation of the brk system call in Ripes doesn't actually do anything; reading https://man7.org/linux/man-pages/man2/brk.2.html brk, on the system side, only returns whether the system call was successful or not. Currently, brk calls are always successful in Ripes - there could obviously be some additional checks in here to ensure that the address passed to brk doesn't override any of the other program segments (.text, ...). But in short, this is why one can write a C program using malloc() in Ripes and things work.

Or I could try to porting sbrk syscall to Ripes?

Yes! i assume you're talking about an assembly implementation here.
brk/sbrk is just managing a pointer at the end of the uninitialized data segment (.bss if present, else the end of .data). So you could do something like the following to simulate a simple dynamic memory management implementation:

.data
# Here goes all of your static data...
a: .word 1
b: .word 2
c: .word 3
d: .word 4
brk_ptr: .word 0
# Define a symbol at the end of your static data segment. This will be where
# your heap will grow from.
_brk_start:

.text

# In your entry point to your program you need to setup your
# dynamic memory management. This also happens in a C program
# when initializing the standard library

_start:
    la t0 _brk_start
    la t1 brk_ptr
    sw t0 0 t1
    j main

main:
    nop
    # ...
    

sbrk:
    # Load the current brk_ptr
    # store it in a temporary reg
    # modify it according to the argument in a0
    # return the temporary reg (brk ptr before modification)

[asahsieh]

Hi @mortbopet
Thank you for your detailed and clear explanation!

About the use of sbrk:

Venus' use of sbrk as ecall code 9 is a bit unconventional and (as far as i am aware of) Venus is the only simulator that actually does this. As mentioned in the issue, Ripes/RARS/... follow the riscv-proxy kernel ABI (as does the GCC toolchain) for system calls (https://github.com/riscv-software-src/riscv-pk/blob/master/pk/syscall.h).

I can get your concern on the use of sbrk. We should follow the riscv-proxy kernel ABI for system calls for implementation.

On the implementation of the brk system call in Ripes:

Please correct me if I am wrong.
Would it be possible to implement the simple dynamic memory management to the execute() method of class BrkSyscall? The concept is to simulate and simplify what the Memory Management in Linux kernel does. If it be done, assembly code to use brk on Rips could be simplified to:

    # ...
    11364:        0d600893        addi x17 x0 214
    11368:        00000073        ecall

The implementation could be optional if user wants to implement own dynamic memory management in assembly code.

[mortbopet]

In theory, one can implement whatever you want inside those system calls; sbrk is a possibility. It's just important to remember that

1. A processor model in Ripes can legally read/write to the entire 32-bit address space. This is of course not the case for "real" processors
2. Given the above, an sbrk implementation essentially boils down to "where do i place the initial starting point of the heap?" and let it grow from there - like the assembly program i provided above.
3. sbrk might be better suited as a userspace implementation given that implementations often relies on information provided by the linker script, i.e. the end-of-data pointer (see https://github.com/riscv-collab/riscv-newlib/blob/riscv-newlib-3.1.0/libgloss/libnosys/sbrk.c). But again, this is not necessary and anything can be done within a system call. You could add some state within a sbrk system call which manages a heap pointer, and return the value of this pointer (like the sbrk assembly function described above, but with the brk_ptr moved to the system call).

[asahsieh]

Hi @mortbopet
Thanks for the updated information.

All things considered, e.g., "where do i place the initial starting point of the heap?", managing a heap pointer, keeping them together in assembly program might be easier and straightforward.

I'll reference the assembly program you provide above and mark your first reply as the answer of this question.

Thank you very much!