Problems porting standard library to my OS

internals
1

I'm writing my own OS in rust and recently started trying to port the rust stdlib to it. I've made it far enough to get a program to compile and be loaded by my kernel, but the stdlib initialization code seems to overflow the stack when it runs. I've given it 16MiB (2x my linux desktop's max) of stack and it eats it all, so don't think its an issue with giving it too small a stack. Right now it's overflowing at the start of rust_panic_with_hook. I've tried to print in PAL common::init and the alllocator, but nothing shows up, I think it just triggers a panic earlier. The PAL I have so far has os::exit, a basic bump allocator, and stdout/err. I've never done compiler work before and don't really know how the stdlib works, so was hoping someone might be able to point me in the right direction, as I'm totally lost right now. This is the link to my rust port: https://gitea.pterpstra.com/mikros/rust/commits/branch/master.

The crt0 I'm linking is just this, all it does is give a dummy ARGC/V and call the exit syscall on main returning:

static char* args[] = {"prog"};

extern int main(int argc, char *argv[]);

void _start() {
  main(1, args);
    asm volatile("  \
    mov $1, %eax; \
    int $0x80; \
  ");
}

Wasn't entirely sure whether this belonged here or on URLO since I'm not actually contributing, but since it does involve the compiler source tree decided to post it here. Thanks for any help.

1 Like
2

i too usually just use println debugging, but when working with low level stuff like this where you don't have consistent access to i/o, you're going to want a proper debugger. usually this would require os support, but it seems like qemu supports facilities for debugging the whole guest system.

these might take a while to set up (expecially if you're using a custom calling convention), but if you want to seriously work on the this os, i'm sure it'll save you time long term.

3

That actually ended up working perfectly, was able to figure out that std makes heavy use of thread-local storage even on a singlethreaded platform for whatever reason. Got a simple implementation set up, and it finally stopped crashing. I was actually trying to avoid that with this post, I was under the impression rust debugging with GDB was somewhat painful, but it was way easier than I expected. Not even my first time using QEMU remote with GDB, I did that all the time with the older C version of my OS.

Thanks for posting after no one else did, getting me to deafetedly try that debugger and realising I was worried about nothing, I guess?

1 Like
4

If you are a single threaded target, you can extend the cfg at rust/library/std/src/sys/thread_local/mod.rs at c1dba09f263cbff6170f130aa418e28bdf22bd96 · rust-lang/rust · GitHub to include your target. This will cause all thread_local!{} to be lowered to statics without requiring any tls support from the OS.

Edit: Never mind, you already found this.

5

This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.