2

I made a very simple 1 stage bootloader that does two main things: it switches from 16 bit real mode to 64 bit long mode, and it read the next few sectors from the hard disk that are for initiating the basic kernel.

For the basic kernel, I am trying to write code in C instead of assembly, and I have some questions regarding that:

  1. How should I compile and link the nasm file and the C file?
  2. When compiling the files, should I compile to 16 bit or 64 bit? since I am switching from 16 to 64 bits.
  3. How would I add more files from either C or assembly to the project?

I rewrote the question to make my goal more clear, so if source code is needed tell me to add it.

Code: https://github.com/LatKid/BasicBootloaderNASMC

Michael Petch
  • 46,082
  • 8
  • 107
  • 198
Tal K
  • 93
  • 12
  • Possible duplicate of [Relocation error when compiling NASM code in 64-bit mode](https://stackoverflow.com/questions/51407270/relocation-error-when-compiling-nasm-code-in-64-bit-mode) – Jonathan Wakely Aug 21 '18 at 10:47
  • Since I can't write an answer you can look at a linker script I wrote for you. I split up the stage2 from the boot sector as well(although it can really be removed an put in bootSector.asm). There is a build.sh file to show how it can be put together Maybe it will give you some ideas. This comment section isn't big enough for me to elaborate. I also placed FREE_SPACE at 0x1000 below the bootloader and out of the way of the kernel.Fixed a bug with jnc $+3 replaced with label. Sectors to load are calculated by the linker. http://www.capp-sysware.com/misc/stackoverflow/51939790 – Michael Petch Aug 21 '18 at 23:59
  • Should also point out that what you are trying to do (link all of the files together and have a combined bootloader and kernel) requires a linker script. If you are willing to separate the different parts and place them on the disk separately you can do that without a linker script but then it is very difficult to share symbols. – Michael Petch Aug 21 '18 at 23:59
  • I've replicated these comments from the chat since they have answered the OPs question and they got it working.Unfortunately with the question still closed I can't provide an actual answer. – Michael Petch Aug 22 '18 at 00:00

1 Answers1

3

since I am also linking a nasm file with the C file, it spits an error from the nasm object file, which is relocation R_X86_64_16 against .text' can not be used when making a shared object; recompile with -fPIC

One of your issues is probably inside that nasm assembler file (which you don't show in the initial version of your question). It should contain only position-independent code (PIC) so cannot produce an object file with relocation R_X86_64_16 (In your edited question, mov sp, main is obviously not PIC, you should use instruction pointer relative data access of x86-64, and you cannot define main both in your nasm file and in a C file, and you cannot mix 16 bits mode with 64 bits mode when linking).

Study ELF, then the x86-64 ABI to understand what kind of relocations are permitted in a PIC file (and what constraints an assembler file should follow to produce a PIC object file).

Use objdump(1) & readelf(1) to inspect object files (and shared objects and executables).

Once your nasm code produces a PIC object file, link with gcc and use gcc -v to understand what happens under the hoods (you'll see that extra libraries and object files, including crt0 ones, -lgcc and -lc, are used).

Perhaps you need to understand better compilation and linking. Read Levine's book Linkers and Loaders, Drepper's paper How To Write Shared Libraries, and -about compilation- the Dragon book.

You might want to link with gcc but use your own linker script. See also this answer to a very related question (probably with motivations similar to yours); the references there are highly relevant for you.

PS. Your question lacks motivation and context (it has no MCVE but needs one) and might be some XY problem. I guess you are on Linux. I strongly recommend publishing your actual full code -even buggy- (perhaps on github or gitlab or elsewhere) as free software to get potential help. I strongly recommend using an existing bootloader (probably GRUB) and focus your efforts on your OS code (which should be published as free software, to get some feedback).

Basile Starynkevitch
  • 223,805
  • 18
  • 296
  • 547
  • Your comments elsewhere show that you don't even understand how complex and arcane a bootloader has to be (for historical reasons: BIOSes need to be able to boot 30 years old systems). Really, give up working on your bootloader (many months of work, even for experts) and focus on your OS thing (you'll learn more and might have more fun doing that) – Basile Starynkevitch Aug 21 '18 at 10:43
  • 1
    I really don't understand how complex and arcane a bootloader has to be, that's why I am trying to write one, even if it takes some time. – Tal K Aug 21 '18 at 10:45
  • Then you should be prepared to fail. We are several to have warned you (and honestly, I understand how exciting coding your OS could be, but I don't understand why you want to spend a lot of efforts on the bootloader. You might even have to reverse-engineer things. – Basile Starynkevitch Aug 21 '18 at 10:46
  • 1
    I am prepared to fail, but eventually I hope I'll get some of it. – Tal K Aug 21 '18 at 10:48
  • Be aware of the [Dunning-Kruger effect](https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect). I feel that you don't understand well what you don't understand and don't know yet. See http://norvig.com/21-days.html – Basile Starynkevitch Aug 21 '18 at 10:52
  • 1
    I do not think I have the knowledge to write that bootloader now, I do think that I can learn that knowledge. – Tal K Aug 21 '18 at 10:55
  • But learning that will take you much more time than you imagine today, and that is less time to work on your OS thing. And some of the knowledge about bootloaders will become obsolete quickly (because firmware and motherboards are evolving quickly). But knowledge about OS will last much more (the things I learned about Unix in 1988 are still useful to me today) – Basile Starynkevitch Aug 21 '18 at 10:55