Porting newlib without execve

[brain]

Hi,

I am planning when i am far enough into OS development to port newlib to my OS then from there use that to compile gcc and binutils for my OS. However, i am unsure as to what will happen if i do not implement execve() in newlib, would this break any possibility of running gcc?

It seems gcc is pretty much tied to unix style schemantics, and i do not want to implement execve() in my OS, i am going to be going for a more CreateProcess style function instead. exec however has special behaviour in that it replaces the text portion of the code and leaves the environment, file handles etc intact, and causes the actual caller to be *replaced* (e.g. it never actually returns) where createprocess would return, and spawn a second process much like fork() and exec() combined.

So in short, can i get away with not implementing execve() and still be able to port gcc?

[pcmattman]

Simply put, no.

Vanilla ports of GCC (no patching) use execve several times during a conventional run (at least once to run "cc1" or "cc1plus", and once more to run "as", and then "collect2" and "ld" if you don't specify "-c"). If you want to port applications which depend on POSIX semantics, you can't get around it.

In my OS, I have a POSIX subsystem which will be separate from the native OS-specific native API, which means it's possible to run POSIX applications alongside native applications. In your case, this would mean a set of POSIX system calls with POSIX semantics (exec and so on), and a set of native system calls with your semantics (CreateProcess).

[Kevin]

If patching gcc (or rather libiberty) is an option for you, it's quite possible to run gcc without separate fork/exec functions. Internally it uses an abstraction on your CreateProcess level, so we implemented pex_tyndur_exec_child and were happy. Of course, with the next POSIX program expecting fork/exec, you need to patch again...