OSDev.org

TheGameMaker90 wrote:Hi there, I've been trying to replace GRUB (because of its limitations and for proprietary reasons) and I was wondering how I could theoretically include say a c header from GAS assembly.
As a preface, I am building my bootloader/kernel in Linux Mint 20 in VirtualBox and I am using the Bare Bones corss compiler (i686-elf) to compile most of my sources. Every once in a while switching to NASM as it seems to have more resources on the internet. My problem is this:
I want to be able to do this

Code: Select all

#include "boot.h"

.code16
.section .text
.globl _start
_start:
    ...
. = _start + 510
.word 0xAA55

The problem is, I don't know how to compile the .S file with the C header. I found no resources on it. It seems to compile the .o when I do i686-elf-gcc -c -m32 boot.S -o boot.o, but how do I turn it into a binary that QEMU can run? Is there special magic? I tried following (to a point) from this https://www.codeproject.com/Articles/66 ... and-C-Part. It basically uses aAS and LD, but when I use LD it says: ld: i386 architecture of input file `boot.o' is incompatible with i386:x86-64 output.

I understand this means the .o file might not have been compiled with the right format, but what can I do to fix this?

TheGameMaker90 wrote:The problem is, I don't know how to compile the .S file with the C header.

/* good */
#define DATA_SEG 0
#define CODE_SEG 1
/* bad */
enum { DATA_SEG, CODE_SEG };

TheGameMaker90 wrote:It seems to compile the .o when I do i686-elf-gcc -c -m32 boot.S -o boot.o, but how do I turn it into a binary that QEMU can run?

TheGameMaker90 wrote:Is there special magic?

TheGameMaker90 wrote:I tried following (to a point) from this https://www.codeproject.com/Articles/66 ... and-C-Part. It basically uses aAS and LD, but when I use LD it says: ld: i386 architecture of input file `boot.o' is incompatible with i386:x86-64 output.

I understand this means the .o file might not have been compiled with the right format, but what can I do to fix this?

TheGameMaker90 wrote:The problem is (perhaps my explanation is off), but I effectively want to be able to use C headers for both. That is, I can call, the parts that the assembly requires in assembly, but use the same header (in an else condition to the macro you supplied) to do things in C.

/* stuff.h */
#define SOMETHING 123

/* src.S */
#include "stuff.h"
movl %eax, $SOMETHING

/* src.c */
#include "stuff.h"
variable = SOMETHING;

movl %eax, $123

variable = 123;

TheGameMaker90 wrote:If you look at GRUB for example, in the file "grub/grub-core/boot/i386/qemu/boot.S" it has a few includes at the top. config.h, grub/symbol., grub/machine/memory.h...

TheGameMaker90 wrote:All I want to be able to be able to do is compile the object file as always and link it similar to that link I posted without a proper linker

TheGameMaker90 wrote:generate a .bin to be run by QEMU.

TheGameMaker90 wrote:What are the command line operators I need to do this. I've already been on the pages you linked and they have helped me not. Thanks.

sebastian wrote:

TheGameMaker90 wrote:Hi there, I've been trying to replace GRUB (because of its limitations and for proprietary reasons) and I was wondering how I could theoretically include say a c header from GAS assembly.
As a preface, I am building my bootloader/kernel in Linux Mint 20 in VirtualBox and I am using the Bare Bones corss compiler (i686-elf) to compile most of my sources. Every once in a while switching to NASM as it seems to have more resources on the internet. My problem is this:
I want to be able to do this

Code: Select all

#include "boot.h"

.code16
.section .text
.globl _start
_start:
    ...
. = _start + 510
.word 0xAA55

The problem is, I don't know how to compile the .S file with the C header. I found no resources on it. It seems to compile the .o when I do i686-elf-gcc -c -m32 boot.S -o boot.o, but how do I turn it into a binary that QEMU can run? Is there special magic? I tried following (to a point) from this https://www.codeproject.com/Articles/66 ... and-C-Part. It basically uses aAS and LD, but when I use LD it says: ld: i386 architecture of input file `boot.o' is incompatible with i386:x86-64 output.

I understand this means the .o file might not have been compiled with the right format, but what can I do to fix this?

You should compile the boot.S file with GNU AS (GAS) and not with GCC, you don't need to compile nothing more if is a only a header, if is a header with C code, you should compile the C code with GCC and link the boot.o and your C code binary with GCC or LD (I recommend using GCC). Also if you don't really know nothing you should use Grub instead.

bzt wrote:

TheGameMaker90 wrote:The problem is (perhaps my explanation is off), but I effectively want to be able to use C headers for both. That is, I can call, the parts that the assembly requires in assembly, but use the same header (in an else condition to the macro you supplied) to do things in C.

Well, yes and no. Yes, you can share the same header file with both, and they both can share the same definitions. But no, you can't put Assembly and C things in that header. You have to limit yourself to a syntax that's common to both, which is not much, mostly pre-compiler stuff (parts which aren't common must be #ifdef guarded).

For example:

Code: Select all

/* stuff.h */
#define SOMETHING 123

Code: Select all

/* src.S */
#include "stuff.h"
movl %eax, $SOMETHING

Code: Select all

/* src.c */
#include "stuff.h"
variable = SOMETHING;

In this case the pre-compiler takes care of it that by the time the text source is passed to the C compiler and Assembler, what they actually receive would be:

Code: Select all

movl %eax, $123

and

Code: Select all

variable = 123;

Neither the C compiler, nor the Assembler parses "#include", and they never see "SOMETHING" either. Those are removed and replaced by the pre-compiler.

TheGameMaker90 wrote:If you look at GRUB for example, in the file "grub/grub-core/boot/i386/qemu/boot.S" it has a few includes at the top. config.h, grub/symbol., grub/machine/memory.h...

Those are nothing more than configuration defines. There's nothing Assembly nor C in them, purely pre-compiler things.

TheGameMaker90 wrote:All I want to be able to be able to do is compile the object file as always and link it similar to that link I posted without a proper linker

Which you can do. Include does not influence linking in any way. Think about include as you would copy'n'paste a text file into another; on the other hand linker operates on binary object files (non-text).

TheGameMaker90 wrote:generate a .bin to be run by QEMU.

Which as I've said, not simple. You must wrap the generated .bin in a disk image in order to run it in qemu. No compiler will do that for you (maybe an Assembler if you code all file system information into your source with 'db' instructions). You'll need other tools than a compiler and a linker. One way is to use dd, losetup, mount etc.
(FYI: the tutorial you linked uses floppy.img as disk image, but the linker outputs test.bin in that tutorial. In section "How to copy the executable code to a bootable device and then test it?" there's (an incorrect) dd command that should update floppy.img with test.bin. The dd command is incorrect as it's missing the notrunc option. Although that tutorial uses bochs, if you did everything right, you should be able the boot floppy.img in qemu too as "qemu -fd floppy.img".)

Another way, which I prefer, is to use a specific tool that generates the disk image for you, that's what mkbootimg is about. It takes a directory and its contents (with your ELF kernel in it) as input, adds the loader to it and wraps all of it, and finally outputs a single binary file which then you can feed to qemu.

TheGameMaker90 wrote:What are the command line operators I need to do this. I've already been on the pages you linked and they have helped me not. Thanks.

Those pages demonstrate exactly those commands. Don't get me wrong, but if those pages haven't helped you at all, then are you sure you have the required knowledge for OSDev?

Cheers,
bzt

TheGameMaker90 wrote:

bzt wrote:

TheGameMaker90 wrote:The problem is (perhaps my explanation is off), but I effectively want to be able to use C headers for both. That is, I can call, the parts that the assembly requires in assembly, but use the same header (in an else condition to the macro you supplied) to do things in C.

Well, yes and no. Yes, you can share the same header file with both, and they both can share the same definitions. But no, you can't put Assembly and C things in that header. You have to limit yourself to a syntax that's common to both, which is not much, mostly pre-compiler stuff (parts which aren't common must be #ifdef guarded).

For example:

Code: Select all

/* stuff.h */
#define SOMETHING 123

Code: Select all

/* src.S */
#include "stuff.h"
movl %eax, $SOMETHING

Code: Select all

/* src.c */
#include "stuff.h"
variable = SOMETHING;

In this case the pre-compiler takes care of it that by the time the text source is passed to the C compiler and Assembler, what they actually receive would be:

Code: Select all

movl %eax, $123

and

Code: Select all

variable = 123;

Neither the C compiler, nor the Assembler parses "#include", and they never see "SOMETHING" either. Those are removed and replaced by the pre-compiler.

TheGameMaker90 wrote:If you look at GRUB for example, in the file "grub/grub-core/boot/i386/qemu/boot.S" it has a few includes at the top. config.h, grub/symbol., grub/machine/memory.h...

Those are nothing more than configuration defines. There's nothing Assembly nor C in them, purely pre-compiler things.

TheGameMaker90 wrote:All I want to be able to be able to do is compile the object file as always and link it similar to that link I posted without a proper linker

Which you can do. Include does not influence linking in any way. Think about include as you would copy'n'paste a text file into another; on the other hand linker operates on binary object files (non-text).

TheGameMaker90 wrote:generate a .bin to be run by QEMU.

Which as I've said, not simple. You must wrap the generated .bin in a disk image in order to run it in qemu. No compiler will do that for you (maybe an Assembler if you code all file system information into your source with 'db' instructions). You'll need other tools than a compiler and a linker. One way is to use dd, losetup, mount etc.
(FYI: the tutorial you linked uses floppy.img as disk image, but the linker outputs test.bin in that tutorial. In section "How to copy the executable code to a bootable device and then test it?" there's (an incorrect) dd command that should update floppy.img with test.bin. The dd command is incorrect as it's missing the notrunc option. Although that tutorial uses bochs, if you did everything right, you should be able the boot floppy.img in qemu too as "qemu -fd floppy.img".)

Another way, which I prefer, is to use a specific tool that generates the disk image for you, that's what mkbootimg is about. It takes a directory and its contents (with your ELF kernel in it) as input, adds the loader to it and wraps all of it, and finally outputs a single binary file which then you can feed to qemu.

TheGameMaker90 wrote:What are the command line operators I need to do this. I've already been on the pages you linked and they have helped me not. Thanks.

Those pages demonstrate exactly those commands. Don't get me wrong, but if those pages haven't helped you at all, then are you sure you have the required knowledge for OSDev?

Cheers,
bzt

In truth I just scan these documents. Tell me exactly where I should look for these commands. I already have everything setuop in my OS except multithreading, tasks, user mode and a buffer for my command line in the keyboard driver. I'm not starting over from "required knowledge." I started working with computers and components from the age of 12. I'm now 27. Computers, programming, digital electronics software and hardware are all I know. My problem is understanding what I read. I find it easier to look at examples, disassemble them piece by piece and create my own algorithms that do practically the same thing in a more efficient way if possible. All I asked for was the commands or at least a pointer to where I can find verbatim what needs to be used. Thanks.

TheGameMaker90 wrote: And my own implementation of stdarg, stdbool, stdint, stdio, stddef, and string.

TheGameMaker90 wrote:I just want to replace GRUB.

TheGameMaker90 wrote:No I shouldn't. I built the bootloader from a tutorial somewhere else then frankenstein-ed the rest from common sense, research and as I mentioned before, disassembling other peopole's sources. Most of the work I've done in the past has been web development, application development for windows and android, game development, and things like that. I'm applying what I know from those fields and my understanding of digital electronics. Knowing how a transistor works doesn't tell me how to build what I need for Operating System development. Especially the specifics of GCC and such. Different applications and packages work differently. And as far as being backed into a corner: Nobody backs me into a corner. Also not to be rude, you might think so, but you don't know me. You can't make a claim to my knowledge without spending five minutes picking my brain. Operating system development is very specific in comparison to what I've worked on in the past and performance and getting things right is extremely important. I simply asked for the line I would need to pass to do it. I will take a look at it again, but I don't see what's so hard about doing something helpful like this:

"Here is what you need to do to create X:
i686-elf-gcc -c -m32 kernel.c -o kernel.o
This should give you what you need."

or

"It's at [insert URL here], scroll down the page and you should see X."

Here is what I actually have in my OS:
- GRUB based bootloader (to be replaces with proprietary bootloader).
- Basic Teletype (terminal)
- GDT
- IDT
- Kernel Heap
- Paging
- CPUID (For detecting Intel or AMD; For later use)
- Keyboard Driver
- Graphic Mode enabled (In NASM Assembly 800x600 32bpp)
- PIT
- IRQ's
- And my own implementation of stdarg, stdbool, stdint, stdio, stddef, and string.

I just want to replace GRUB.
Thanks.

Required Knowledge wrote: Language and Vocabulary, pt. 2: Most operating systems featured on this site, as well as most of the code snippets and examples, are written in C (or C++). Even if you choose to use another language (like FreeBASIC or Pascal), C is the lingua franca of programming, and you should be competent in making heads and tails of it.
Assembly: You should have knowledge about the low-level language Assembly. Read a book. Take a course at school. Write some user-space code to familiarize yourself with it. You will need it, even if you plan to write most of your operating system in a higher-level language.

TheGameMaker90 wrote:It seems to compile the .o when I do i686-elf-gcc -c -m32 boot.S -o boot.o, but how do I turn it into a binary that QEMU can run? Is there special magic? I tried following (to a point) from this https://www.codeproject.com/Articles/66 ... and-C-Part. It basically uses aAS and LD, but when I use LD it says: ld: i386 architecture of input file `boot.o' is incompatible with i386:x86-64 output.