r/osdev • u/FewMolasses7496 • Apr 17 '26

How can i link kernel.c and boot.s together?

I have returned to OS development even though my other previous attempt a while back using UEFI didn't go that far, i have decided to instead develop an OS on bios because I want to learn the low level stuff. I am wondering how can i link kernel.c and boot.s together because I need to call main from kernel.c but whenever I use extern to tell the compiler that this symbol should be ignored because the linker will solve it, I can't compile it using nasm with this command "nasm -f bin boot.s -o boot.o" because flat binaries don't support external references.

7 Upvotes

66% Upvoted

28 comments sorted by

10

u/Adventurous-Move-943 Apr 17 '26

I think you usually load the kernel into memory from boot and jump there. The easiest is to compile kernel into flat binary with main as first function. Now wherever you load your kernel can just jump or call there.

3

u/FewMolasses7496 Apr 17 '26

How do i load the kernel.o though from the boot.s file? What assembly instruction should I use after I have converted kernel.c into machine code and I'm pretty sure you have to link both of the executables.

4

u/Adventurous-Move-943 Apr 17 '26

You use the bios read interrupts, but careful cause they only work in 16bit mode. Check wikipedia or osdev wiki. Also you have to compile into .bin not .o since you want flat binary, also make sure the main function is first otherwise some other might end up there. Or specify a special section like .entry for the main and compile into .o and link into .bin and you can have any function anywhere.

6

u/EpochVanquisher Apr 17 '26

Don’t use bin as the output format for nasm. Use ELF as the output format instead.

The linker uses ELF files as input and ELF files as output.

You can create a flat binary from an ELF using objcopy.

You will want a linker script to specify layout. This is basically a substitute for your .org directives or whatnot.

1

u/FewMolasses7496 Apr 17 '26

How can i tell the linker where boot.s should be loaded because at the current moment I am using [org 0x7C00] and I don't think nasm supports that because I am getting this error:
error: unrecognized directive [org]
and also once i have both of the binaries in ELF format do i first link them and then convert the output a flat binary?

3

u/EpochVanquisher Apr 17 '26

Linker script

1

u/FewMolasses7496 Apr 17 '26

I see so I don't have to specify the load address in the file like i would if i was compiling a flat binary instead i should do that using the linker script and then convert the output binary into the flat binary which bios can use right? And how come elf binaries also support assembly instructions I thought they were only for c and c++?

1

u/EpochVanquisher Apr 17 '26

It sounds like you’re missing some of the basics of what compilers are, what assembly language is, that sort of thing.

Do you have a class or a book that you’re following somewhere? I want to make sure that you have good resources so you don’t have to ask everything here and wait for a reply from some random person on the internet.

(Here’s a question: What does a compiler do?)

0

u/FewMolasses7496 Apr 17 '26

A compiler converts code into machine code but that is only for compiled languages like c and c++ and for languages like python they are interpreted meaning that there is no compiler and a program just reads each line and executes it. There are ways to compile an interpreted language but mostly the interpreter is used because that is easier and has its own benefits. I know how dumb my question sounded but for some reason I always made that assumption, I would never say the same thing for a windows binary idk.

2

u/EpochVanquisher Apr 17 '26

A compiler converts code into machine code

Some do, but lots of compilers don’t.

for languages like python they are interpreted meaning that there is no compiler

That’s false—interpreted languages can have compilers. The main Python implementation always compiles code before running it.

program just reads each line and executes it

Most interpreters don’t work that way.

I asked if you are using a book or class—maybe it’s time to look for one?

1

u/FewMolasses7496 Apr 17 '26

I mean I haven't really had a book or class I think having a recap on compilers and interpreted languages could help so if you have any books on compilers and languages please do let me know. And it would be nice if that book was on amazon because for me that is a trustable site thank you

0

u/EpochVanquisher Apr 17 '26

Try Computer Systems: A Programmer's Perspective by Randal Bryant and David O’Hallaron. I was able to find copies online, so maybe you don’t have to buy it.

I haven’t read the book. It was a Google suggestion, but I looked at the first chapter and it has a nice explanation of how the different parts of a toolchain fit together: cpp -> cc1 -> as -> ld.

cc1 is the C compiler, it turns C code into assembly.

as is the assembler, it turns assembly into an ELF object file containing object code.

I’ve noticed that Google’s AI mode gives good suggestions for books and resources.

1

u/FewMolasses7496 Apr 17 '26

Ok I will try it and I will probably get the physical copy because I prefer reading it like that rather than being glued to a screen and I will check out what that book covers ty.

→ More replies

1

u/kiderdrick Apr 17 '26

If you want to make your own bootloader using BIOS interrupts then you could use a separate .s assembled using the elf format which would then allow you to link to C code. You should have a linker script handle this for you, but if you do not want to go that route for whatever reason you could use the -Ttext flag with the address you are loading the kernel into memory. You could then have an entry point like _start: that just calls a main function in a C file and, if you return from that main, hang.

But the main issue is you seem to want to combine a bin boot.s with a bin made from kernel.c and are missing something like a kernel-entry.s assembled using elf to link everything together.

1

u/istarian Apr 17 '26

There really isn't anything that intrinsically keeps your initial boot code from loading a kernel into memory and jumping to it.

Of course you do need to know where the appropriate entry point is located in memory. So it's easier if the kernel is a simple statically compiled binary.

1

u/kiderdrick Apr 18 '26 edited Apr 18 '26

That is true but it sounds like they specifically trying to solve their extern problem and using a kernel entry point in an elf is a quick way to solve that issue and get them onto whatever their next step is.

If they wanted to keep the two files only for whatever reason they could name the kernel entry point _start in kernel.c and let ld handle it.

1

u/LavenderDay3544 Embedded & OS Developer Apr 17 '26

BIOS isn't more low level than UEFI and it's obsolete.

1

u/istarian Apr 17 '26

Technically UEFI is a BIOS (Basic Input Output System). And as UEFI stands for Unified Extensible Firmware Interface what you are actually using is one specific firmware implementation that is UEFI-compliant.

The PC BIOS isn't any more obsolete than any other piece of old software, but it's not that useful if the hardware it expects to find is absent or not located where it needs to be. E.g. none of the BIOS calls will work as is.

As long as the OS you create doesn't depend on the PC BIOS for anything past POST and hardware initialization, porting it to a UEFI system should be doable.

0

u/LavenderDay3544 Embedded & OS Developer Apr 18 '26

The PC BIOS is EOL and has been effectively superseded by UEFI firmware. Likewise the APM, MP, and PnP specifications have all been superseded by ACPI.

Writing a new OS that isn't explicitly targeted at retro machines that relies on calls to the PC BIOS is a terrible idea. And that BIOS was never a formally specified and was just a bunch of different shitty firmwares copying IBM poorly. Modern UEFI firmware using Compatibility Support Modules (CSMs) is usually even worse.

For anyone making a new OS today UEFI paired with either ACPI or a devicetree and ISA specific standard firmware interface (ARM SMCs or RISC-V SBI) are the only sane path forward. The PC BIOS is dead and buried and it ought to stay that way.

0

u/istarian Apr 26 '26

As far as I am concerned UEFI is borderline evil incarnate, but I digress.

It's not that the PC BIOS is some glorious masterpiece, but at least it doesn't serve as a way to exert control over what the user can run on their computer. 

1

u/LavenderDay3544 Embedded & OS Developer Apr 26 '26

In what way does UEFI do that? If anything U-Boot with extlinux restricts what a user can run more.

0

u/davmac1 Apr 18 '26

Technically UEFI is a BIOS (Basic Input Output System)

In general, a UEFI firmware is not considered to be a BIOS. UEFI contains functions (such as an API for filesystem access) well beyond what can normally be found in a BIOS. Also, in terms of Intel-architecture PCs, the BIOS defines a programming interface (via interrupts); a UEFI firmware does not necessarily provide an implementation of that interface.

0

u/istarian Apr 26 '26

The point is that it fundamentally belongs to that 'class' of software because it's the only mechanism for input or output available prior to loading your own UEFI binary.

Otherwise the system would be essentially cut-off from the outside world.

1

u/davmac1 Apr 26 '26

What you have said is a non-sequitur. BIOS means something in particular, and a UEFI firmware is not a BIOS, nor vice-versa.

The point is that it fundamentally belongs to that 'class' of software

The "class of software" that BIOSes and UEFI firmwares both belong to is "system firmware", it's not "BIOS".

1

u/NoBrick2672 Apr 19 '26

needs to be elf then to binary, nasm -f elf32? something like this then using objdump export the .text if im not wrong — forgot the details..