OSDev.org

Hi all!

I have built a kernel loader in asm.
It loads a sector from the floppy and then execute it.
My problem is when I try to load a c kernel compiled with dgjpp,
it never executes the code but when i write the kernel in asm, it works.
Can someone explain me why ??
Someone told me about protected mode. DGJPP generates pm code and my boot loader
doesn't set it, this is why it doesn't work... Is it right ?

>I have built a kernel loader in asm.
>It loads a sector from the floppy and then execute it.
>My problem is when I try to load a c kernel compiled with dgjpp,
>it never executes the code but when i write the kernel in asm, it works.
>Can someone explain me why ??
>Someone told me about protected mode. DGJPP generates pm code and my boot loader
>doesn't set it, this is why it doesn't work... Is it right ?

Someone really oughta make a OS-Dev FAQ
Actually... someone did, I think...

Anyway, there's two problems here.
1) You _cannot_ directly jump to a C/C++ compiled
piece of code, even it it's compiled into a binary
file. Why? Well, where's the entry point? You
can't possibly tell! 0x0 is _NOT_ where the compiler
linker will put _main.

You _must_ write an asm stub for the C/C++ object.

2) You're right... if you try and run djgpp compiled
code in real mode it will not function correctly. For
example, while djgpp thinks its accessing the entire
eax register, it will, in fact, by accessing only
half of it, ax. The reverse is also true if the
32/16-bit prefix (0x66 ?) is used.

Jeff

>On 2001-12-26 18:15:21, j.weeks wrote:
>
>Someone really oughta make a OS-Dev FAQ
>Actually... someone did, I think...
>
>Anyway, there's two problems here.
>1) You _cannot_ directly jump to a C/C++ compiled
>piece of code, even it it's compiled into a binary
>file. Why? Well, where's the entry point? You
>can't possibly tell! 0x0 is _NOT_ where the compiler
>linker will put _main.
>
>You _must_ write an asm stub for the C/C++ object.
>
>2) You're right... if you try and run djgpp compiled
>code in real mode it will not function correctly. For
>example, while djgpp thinks its accessing the entire
>eax register, it will, in fact, by accessing only
>half of it, ax. The reverse is also true if the
>32/16-bit prefix (0x66 ?) is used.
>
>Jeff

Thank you for your answer !

1) I thought that when I link with "ld -o test -Ttext 0x0 -e main test.o",
it puts the entry point was 0x0

2) Ok! So, I will test some experimentations in pmode )

Thank you again for these explanations.
(BTW I haven't found the FAQ... :/)

>>Jeff
>
>Thank you for your answer !

No prob.

>1) I thought that when I link with "ld -o test -Ttext 0x0 -e main test.o",
>it puts the entry point was 0x0

Unfortunately, no. All it does it make sure that all
the code is outputted to assume that, when loaded,
it will exist at 0x0.

Ordinary, _start would exist at ProgramOffset + main,
but in this case it would exist at 0x0 + main (which
isn't necessarily 0x0, of course).

>2) Ok! So, I will test some experimentations in pmode )

You might wanna try real mode first, just to make
sure. It's easier for testing purposes.

I just do something like this for a stub:

jmp asmEntry
; define any variables you might need

asmEntry:
; do whatever

; call your C entry point
jmp _main

and then make sure that's the first file on your
linker line, and you're all set. The binaries
entry point will then be 0x0.

>Thank you again for these explanations.
>(BTW I haven't found the FAQ... :/)

Its out there somewhere...
Check out http://www.nondot.org/sabre/os/articles
for some good info on booting and other stuff.

Jeff