[FIXED] Any ideas why trying to use "mmap" throws a segmentation fault?

[rempas]

I'm trying to implement the "mmap" system call on Linux 64bit. I have the following code:

/* mmap system call */
/* Protections */
enum PROT_READ  = 0x1; /* Page can be read.  */
enum PROT_WRITE = 0x2; /* Page can be written.  */
enum PROT_EXEC  = 0x4; /* Page can be executed.  */
enum PROT_NONE  = 0x0; /* Page can not be accessed.  */

/* Flags */
enum MAP_SHARED    = 0x01; /* Share changes.  */
enum MAP_PRIVATE   = 0x02; /* Changes are private.  */
enum MAP_FIXED     = 0x10; /* Interpret addr exactly.  */
enum MAP_ANONYMOUS = 0x20; /* Don't use a file.  */

@extern(syscall, 9)
void* sys_mmap(void* addr, u64 len, i32 prot, i32 flags, i32 fd, i64 off);

void* malloc(u64 len) {
  return sys_mmap(null, len, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, -1, 0);
}

void main() {
  u8* val = cast(u8*)malloc(4096); // PAGESIZE
  *val = 10;

  exit(0);
}

I got the signature for "mmap" from the man pages. This code will work under C but it will throw a "segmentation fault" on Vox when I try to de-reference the pointer. Any ideas?

[MrSmith33]

I tested in WSL and mmap returns 0xffffffffffffffea (-22) for me

[MrSmith33]

It works if I call it directly, without the wrapper function

void main() {
    //u8* val = cast(u8*)mmap(null, 4096, PROT_READ | PROT_WRITE, MAP_PRIVATE | MAP_ANONYMOUS, 0, 0); // works
    u8* val = cast(u8*)malloc(4096); // fails
    *val = 10; // fails here
    exit(0);
}

[MrSmith33]

may be a bug in codegen

[rempas]

Yeah I can also confirm that it works without the wrapper function.

[rempas]

At least I know now that my code is ok and I can continue, thanks!

[MrSmith33]

ok, the stack layout was indeed wrong, but wasn't what cause the problem, it is codegen of mmap function that is incorrect. It ends up passing 0 as parameter to mmap syscall

[MrSmith33]

And 0xffffffffffffffea (-22) means EINVAL, which is 22 in linux. It is just mmap docs that only talk about -1 being returned in case of an error.

[MrSmith33]

Fixed #33

[rempas]

This is now fixed after the last commit! Thanks a lot for your amazing work!!