Bare Bones gone wrong... (can't compile)

[fingerprint211b]

First of all, hello (new member)
I've been trying to get into OS development for some time now. I have almost no experience with assembly (just a few days, I'm reading 'Art of Assembly' in hope of learning it), but I have some experience with C (I'm not a beginner any more, but I'm not really satisfied with my knowledge either), so I thought I'd join the community to learn how operating systems really work. Maybe some day even create my own little os

Anyway, I was trying to follow the Bare Bones tutorial from wiki ( http://www.osdev.org/wiki/Bare_bones ) and I understood it rather well (some parts of assembly code I don't understand yet, but I figure I will, once I gain more experience). I have tried to compile it, only to hit a solid brick wall. So, here's my problem (hopefully someone will help), or rather- the log of things I did :

1. When trying to compile kernel.c, I get an error saying :

Code: Select all

kernel.c:1: warning: unused parameter ‘mbd’
kernel.c:1: warning: unused parameter ‘magic’

Of course, this is due to the -Werror switch tutorial said I should use when compiling
So, I decided to compile without -Werror ...

2. NASM gave me loader.s with no problems...

3. When I try to link the two files (while passing linker.ld script to ld), I get this :

Code: Select all

loader.o: In function `_loader':
loader.s:(.text+0x14): undefined reference to `_kmain'

the error occures in this part of code :

Code: Select all

call    _kmain

Any idea why this could be?
Thank you in advance.

edit :
Just in case it matters, I will list the versions of programs I'm using :
GNU make : 3.81
gcc : 4.2.3
nasm : 0.99.06-2
ld : 2.18.0.20080103
Under Kubuntu 8.04, with 2.6.24-16 kernel.

[itisiuk]

the

kernel.c:1: warning: unused parameter ‘mbd’
kernel.c:1: warning: unused parameter ‘magic’

are just warnings cos your not using them so dont worry about that.

as for

loader.o: In function `_loader':
loader.s:(.text+0x14): undefined reference to `_kmain'

try removing the _
so

extern _kmain becomes just extern kmain

and
call _kmain is again just call kmain

thats assuming you linking them together correctly. you would really need to post your code and makefiles too see exactley what your doing.

[fingerprint211b]

Thank you, that DID work.
Still I don't understand why the assembly source called _kmain, when kmain was declared in kernel.c ?

Now, I have a few more questions :

Code: Select all

unsigned char *videoram = (unsigned char *) 0xb8000;

in kernel.c alters video memory, and should be equal to this :

Code: Select all

      
mov ax,#0xb800
mov es,ax
seg es
mov [0],#0x41
seg es
mov [1],#0x1f

This is a BIOS interrupt, right?
Can you point me to a list of BIOS interrupts?
es stands for 'extra segment register', right? But what does that mean ?

[tadada]

Ok for you first question. A compiler (I don't know which) adds _ to the beginning of functions so you must call them with the _.

That is not an interrupt. That is moving data into ram which is then loaded by the GFX card.

If you are in pmode the interrupts are not avalible but in real mode they are. Like on the resources page in the wiki. Not only does it have what you want (in the software specs section) but also a lot more useful information.

Extra Segment means it doesn't have a job like CS, DS, SS, and the others do. (CS refrences CODE for example and DS refrences DATA) Basically you can use ES for what ever you want. In you case you are using it to hold the spot in ram where video is stored (plus the exact position in the VID ram. By moving 2 spaces up in ram you move 2 1 space on the screen. Even spots in the ram hold charecters and odd spots hold the attribute saying what color it is, plus a bit more.)

[jinksys]

From : http://www.osdev.org/phpBB2/viewtopic.p ... underscore

this was another thing i thought about asking, why the built-in functions and in the headers files they use __

Everything you never wanted to know about those underscores ...

In source code (usually C code), single-underscore is reserved for the OS / system libraries and double-underscore is reserved for the compiler implementation.

This is why (on Linux) you get functions like exit(), which is the POSIX-compatible version that runs atexit() functions, and _exit(), which is a raw syscall that immediately and unconditionally terminates the process. fork() handles all the libc locking, while _fork() is the raw syscall that immediately starts a new process (and probably deadlocks the next time you call into libc because the internal libc locks never get released).

And this is why if you peek at the compiler's header files (e.g. stdint.h), you'll find a lot of macros and types with double-underscores. GCC uses __attribute__ (note the double-underscores) as a language extension, MSVC uses __int64 or __int128 for types that don't exist in the C language. The C specification is very particular about what symbols are allowed in the global namespace, so the compiler puts all its configuration in the compiler-reserved namespace so the compiler's symbols don't conflict with your program.

For the addition of a leading underscore ... most old formats (COFF, upon which Microsoft compilers are based, the old Unix a.out format, MacOSX mach-o) prepend an underscore to all symbol names in C files. I believe this was to avoid accidental (and hard-to-debug) name conflicts between C symbols and temporary assembly symbols generated by the compiler. But when ELF was created, the implementors decided the reasons for doing so were no longer relevant (GCC uses a prefix character that C code cannot generate), so they dropped the implied leading underscore to save a few bytes.

[fingerprint211b]

Thanks!

[Candy]

Actually, afaik, the underscore was added in all the original C compilers that were to coexist with Fortran to avoid name collisions with Fortran functions. You should then also be able to declare them as extern "fortran" or something and get the underscore to go that way.

Why Microsoft etc. still do that is a puzzle to me, but probably just compatibility.

[JAAman]

Extra Segment means it doesn't have a job like CS, DS, SS, and the others do.

actually it does... the ES segment is implied for string operations referencing DI (iirc)

[fingerprint211b]

It seems I've got a lot to learn...
Thanks!