Compling errors

[DarylD]

Abless..Not if you want super-fast inlined functions.

I put them in header files, so long as they aren't large.

[Schol-R-LEA]

Abless..Not if you want super-fast inlined functions.

I put them in header files, so long as they aren't large.

That only applies to member functions in C++; standard C does not inline functions at all, nor will ordinary functions inline in C++ IIRC. Also, you want to limit inline functions to those where the function call overhead significantly impacts the performance, such as get/set operations(that is, functions who sole purpose is to read or change a protected instance variable). Inlining the majority of you functions is a Bad Thing, if only because you then have multiple copies of the same code bloating up your executable.

[beyondsociety]

On a guess, though, what is happening is that either you haven't put function prototypes for printk() and and clear_screen() in the matching header files, or else you aren't including the header files in your main.c file.

No, I checked my code and its included in there.

Also, what is 'kernel.bin'? Is this supposed to be bootpm.bin (I doubt it, but I don't know what your design plans are), or is it something else entirely?

Kernel.bin is the binary file made when I link main.o and ks.o together, forming the kernel. Bootpm.bin is copied seperate first to the disk using partcopy and then kernel.bin using partcopy also.

Also, while you specify flat-binary object format for bootpm.asm, and a.out object format for ks.asm, you seem to be leaving the C code at the default object format, which is ELF. Aside from the problems of linking ELF to a.out, there are also differnces in how it handles extern function names; specifically, it does not automatically assume that extern functions are prefixed with an underscore. If the function manes are prefixed, but the prototypes are not (as would be the case with traditional C compilers and linkers), the link will break under ELF, IIUC.

I'll have to check into this as in my ks.asm file, I jump to the c kernel like this:

Code: Select all

jmp _k_main

If what you said is true, this might be my problem.

Whats the difference between these two forms of including a file in my kernel?

Code: Select all

#include <stdio.h>

Code: Select all

#include "stdio.h">

[Schol-R-LEA]

Kernel.bin is the binary file made when I link main.o and ks.o together, forming the kernel. Bootpm.bin is copied seperate first to the disk using partcopy and then kernel.bin using partcopy also.

Oh, of course... it's just after the '-o' (output filename) option, isn't it? <kicks self>

Whats the difference between these two forms of including a file in my kernel?

Code: Select all

#include <stdio.h>

Code: Select all

#include "stdio.h"

AFIAK, it determines the search path used to find the files by the preprocessor. Using angle brackets causes the preprocessor to search in the [tt]/include[/tt] directory for the compiler; using double-quotes makes it look in the local directory.

C&CW.

[Pype.Clicker]

AFIAK, it determines the search path used to find the files by the preprocessor. Using angle brackets causes the preprocessor to search in the [tt]/include[/tt] directory for the compiler; using double-quotes makes it look in the local directory.

<file> is not limited to the compiler/include directory, but can be extended to every directory added to the include set (with -Idirectory in gcc) and compiler/include/* can be excluded (useful for OSdev) using -fno-std-include ...

[beyondsociety]

I need some help.

When I put everything in one file, it print my message to the screen fine. But if I use seperate files consisting of: main.c, video.c, video.h, it compiles fine, but I either get a tripple fault in bochs or nothing is printed to the screen. What could be the problem?

main.c

Code: Select all

#include "video.h"

void main()
{
   k_print("IBOX Operating System");
   for(;;);
}

video.c

Code: Select all

#include "video.h"
#define WHITE_TXT 0x07;

void k_print(char *str)
{
    char *video = (char *) 0xb8000;

    while(*str)
    {
   *video++ = *str++;
   *video++ = WHITE_TXT;
    }
    return;
}

video.h

Code: Select all

/* Prototypes */
void k_print(char *str);

How I compile it

Code: Select all

@ECHO OFF
nasm -f bin bootpm.asm -o bootpm.bin ; Bootsector
nasm -f aout ks.asm -o ks.o                  

gcc -ffreestanding -c main.c -o main.o 
gcc -c video.c -o video.o

ld -T link.ld -o kernel.bin main.o ks.o video.o

bootcopy bootpm.bin 0
bootcopy kernel.bin 1

makeboot test.img bootpm.bin kernel.bin

Ks.asm

Code: Select all

[BITS 32]
[GLOBAL start]
[EXTERN _main]       ; This in the C Kernel

start:

     call _main
     jmp $

link.ld

Code: Select all

OUTPUT_FORMAT("binary")
ENTRY(start)
SECTIONS
{
 .text  0x100000 : {
   *(.text)
 }
 .data  : {
   *(.data)
 }
 .bss  :
 {                               
   *(.bss)
 }
}

[Schol-R-LEA]

This brings to mind another recent question and it's resolution. In that instance, it turned out that the order in which object files were linked by [tt]ld[/tt] was significant. Is it possible that this is the case here? Perhaps you should try linking with the main.o and ks.o arguments reversed, like this:

[tt]ld -T link.ld -o kernel.bin ks.o main.o video.o[/tt]

This would place the stub code at the begining of the executable image, which is presumably where the kernel execution starts.

Pardon me if I am wrong here, as this isn't an area I am all that strong on, personally.

[distantvoices]

It is, as scholar here says

The Entry point to the kernel image has to be linked at the very beginning of it! This is, because the bootloader jumps just to the first address of the kernel image. If you load it at 0x10000, then an address 0x10000 shall be an instruction: f. ex. the entry point of your kernel.

The linker needs to know what the entry point is and it needs to get the module containing the entry point FIRST. so it puts the first instruction at address 0x10000 - the beginning of the .text section.

stay safe

[beyondsociety]

I did a objdump and it shows that it starts at address 0x00000000. It should be 0x00100000 considering thats were I'm loading my kernel.

Any suggestions why its doing this?

[Pype.Clicker]

i guess you missed the -Text (or something alike) instruction that forces the linker relocating your kernel code. Check you're looking at the VMA, not the physical (in file) address, though.

[beyondsociety]

Its fixed. There was not a problem with my C code but in fact a problem with my assembly bootloader.