Page 1 of 1

Creating programs

Posted: Sun May 07, 2023 1:20 am
by SanderR
Hello everyone,

I have questions about creating programs.
Let's say I want to port NASM, what is the best practice to link the program?
Does it mean I need to change the linker script and add an object file to the binary with the stdlib of my OS?
Or is there a better way to do this?

Re: Creating programs

Posted: Sun May 07, 2023 1:35 am
by nullplan
That highly depends on how development for your OS works. In my case, I am attempting to emulate Linux a lot, so that will likely mean porting gcc or clang and binutils to my OS (which is mostly just about telling them about it and setting a few config options), which shouldn't be hard, and then I can use the normal compile scripts for all the other programs.

Re: Creating programs

Posted: Sun May 07, 2023 2:00 am
by SanderR
nullplan wrote:That highly depends on how development for your OS works. In my case, I am attempting to emulate Linux a lot, so that will likely mean porting gcc or clang and binutils to my OS (which is mostly just about telling them about it and setting a few config options), which shouldn't be hard, and then I can use the normal compile scripts for all the other programs.
Thank you for your answer.
And you port GCC and Binutils by adding your own standard library to the linker script? Currently, I got a working port of FASM using this method, but I was thinking it could be a setting on my end that I needed to configure to make it all a bit easier.

Re: Creating programs

Posted: Sun May 07, 2023 3:21 am
by nullplan
SanderR wrote:Thank you for your answer.
And you port GCC and Binutils by adding your own standard library to the linker script? Currently, I got a working port of FASM using this method, but I was thinking it could be a setting on my end that I needed to configure to make it all a bit easier.
Not really. I plan on writing a C library or else porting musl or something (not quite sure about that since musl is a pure Linux libc, and quite a few things depend on Linux as OS when you wouldn't think it). Then for binutils, not a whole lot of effort is even needed to compile it (as all the low-level stuff is compatible), and for GCC, I just need the right specs file. The OS interface is UNIX compatible. I don't know why you are so hung up on linker scripts, as my OS is capable of accepting all correctly linked ELF files, so I really don't care about the layout. The specs file is GCC's configuration which tells it where to find everything. But also, most of the paths and names will be compatible. There will not be a crti.o or crtn.o (those are just silly, and not needed in anything newer than ca. the turn of the millenium). There will still be a crt1.o (containing the _start symbol), and the libc will be called libc.a and installed in /lib.

Seriously, I think the hardest thing will be to rid these programs of their love for dynamic linking. I don't plan on having that at all for now (which simplifies the C library to no end), but it also means there will be nothing capable of interpreting relocations. So no dynamic libs, and no PIEs, not even static PIEs. But once that is taken care of, the rest should go smoothly, since then it is just Linux with less features.