Wrong tests for qsort and hello.

[victorlisman]

The mapping for the segments for qsort work just fine, even though it segfaults at the end(when jumping to the base_adress,, tried debugging with gdb, it maps just fine just segfaults). Picture for reference: For hello, the output is the same length, as it should be, it maps just fine, and exits with the correct code. For some reason it does not print the characters and instead fills it with NULL. Pics for refrence:

[alexandruradovici]

Did you map the correct data section in the memory? Bss and data may be in the same page, in this case it means rthat you have to zero out the bss part yourself.

[victorlisman]

Hmmmm, it seems to have fixed the issue for the hello output, but here is something I am really confused about. If I transmute the entry point into an anonymous function at the end of executing, hello outputs correctly, but qsort segfault by going into kernel space??????. If i don't transmute at the end, both qsort and hello return the correct codes(0) and map correctly, but they don't output anything.

[alexandruradovici]

What dors transmute the entry point mean?

[victorlisman]

I call std::mem::transmute on the entry point and allocate as a const fn pointer to an extern C fn, and then subsequently call that fn. This is wrapped into an unsafe block.(I do this at the end of the exec fn) For some reason this makes hello work correctly, but segfaults qsort. If I comment it out, both qsort and hello map and return correctly, but output nothing.

[alexandruradovici]

You should never do that, starting the elf is not just that. We have the runner module for that.

[victorlisman]

I know, I just wanted to know why hello only outputed when i did that

[alexandruradovici]

The elf loader does not directly call your entry point, it has to set up the arguments and the environment variables.