Elf vs Binary?

[Raven]

Hi
I recompiled James kernel and was loaded fine by GRUB but when i changed linker script to OUTPUT_FORMAT("binary") it shows page_fault when i tried to load it using my Second-Stage Bootloader.
My binary kernel is loaded fine by my BootLoader compiled using same linker script.
My BootLoader loads binary kernels at 0x100000 and i removed initrd from James Kernel.
Compilation of edited James kernel shows no errors.

My SSBootloader sets up GDT and IDT which is later changed by my kernel but no TR is set.
Where I went wrong in my SSBootloader?
Or is there something in James kernel that stops it from running smoothly when compiled to binary?
Please help

[captainwiggles]

not sure if this will help, but with grub, if the kernel is not an elf binary you need some additional multiboot headers. your entry point should have something like:

Code: Select all

    MULTIBOOT_PAGE_ALIGN	equ 1<<0
    MULTIBOOT_MEMORY_INFO	equ 1<<1
    MULTIBOOT_AOUT_KLUDGE	equ 1<<16
    MULTIBOOT_HEADER_MAGIC	equ 0x1BADB002
    MULTIBOOT_HEADER_FLAGS	equ MULTIBOOT_PAGE_ALIGN | MULTIBOOT_MEMORY_INFO | MULTIBOOT_AOUT_KLUDGE
    MULTIBOOT_CHECKSUM	equ -(MULTIBOOT_HEADER_MAGIC + MULTIBOOT_HEADER_FLAGS)
    EXTERN code, bss, end

    ; This is the GRUB Multiboot header. A boot signature
    dd MULTIBOOT_HEADER_MAGIC
    dd MULTIBOOT_HEADER_FLAGS
    dd MULTIBOOT_CHECKSUM
    
    ; AOUT kludge - must be physical addresses. Make a note of these:
    ; The linker script fills in the data for these ones!
    dd mboot
    dd code
    dd bss
    dd end
    dd start

I copied that straight from the 3rd page of http://www.osdever.net/bkerndev/index.php so check there for more specific details. I can't remember which flag it specifically is, but a few of those can be romeved if you use elf, as grub assumes elf as default.

Wiggles

[pcmattman]

if the kernel is not an elf binary you need some additional multiboot headers

it shows page_fault when i tried to load it using my Second-Stage Bootloader

In other words, it's not GRUB .

Basically, you need to find out where that page fault happens and then figure out why it's happening. You can use Bochs to find the faulting EIP, and you can write text to the screen to find out where it's executing.

[egos]

I used this source in fasm for testing GRUB.

Code: Select all

; --------------------
; Kernel stub for GRUB
; --------------------

MBH_MAGIC equ 0x1BADB002
MBH_FLAGS equ 0x10000

  use32

  org 0x100000
load_addr:
header_addr:
  dd MBH_MAGIC
  dd MBH_FLAGS
  dd -MBH_MAGIC-MBH_FLAGS
  dd header_addr
  dd load_addr
  dd load_end_addr
  dd bss_end_addr
  dd entry_addr

entry_addr:
  jmp $

load_end_addr:

bss_end_addr:

[Raven]

Hi
Thanks alot for your posts
I apologize for delay and thank you for your posts.
Well, thanks for letting me know about additional headers for binary.
My problem is that i have my own bootloader that just loads binary nothing else.
when i compiled my kernel to binary it is loaded fine by my bootloader which checks for no headers like stuff.
It just locates file and loads complete file at 0x100000 address. It does so by setting up GDT and some dummy exception handlers.

Now, i tried to load JamesM's kernel BUT before that compile it to binary rather than elf.
As soon as my bootloader loads that kernel it shows page-fault ( exception handler of JamesM kernel is fired ).
This means that James kernel is loaded, while if its elf variant is loaded using GRUB no fault.

Does binary file broke on compilation, couldn't maintain the integrity?

Please comment

[pcmattman]

Hi,

As soon as my bootloader loads that kernel it shows page-fault ( exception handler of JamesM kernel is fired ).

Right, so you know it's at least getting to the kernel. Where's it page faulting, exactly? Write in some debug output lines to write some stuff to the screen so you can see where it is before it crashes. Keep in mind after those output lines you might want something like "while(1);"

[Raven]

Hi
Yeah got it
The page-fault is when the multitasking intialisation routine does move stack.
In this routine when

Code: Select all

memcpy((void*)new_stack_pointer, (void*)old_stack_pointer, initial_esp-old_stack_pointer);

is executed for BINARY page-fault happens and when executed for elf no page fault happens.

Now, what i did as i am not using fork(), i commented movestack() and it is working fine in elf and binary.
What is wrong with this function in binary format cannot get it.

[Raven]

Hi
No that binary behaves erratically, any ideas?

[01000101]

You should check the values given to memcpy() (print them) before you use it. If the values are sane, then make sure interrupts are disabled before you execute the memcpy(). Also, be sure that the stack starts on a 4/8 byte aligned memory location.
[edit] not all of those would result in a page-fault, but they need to be checked anyways [/edit]

[Raven]

Hi
Still not able to understand why it shows PF on memcpy ONLY IN BINARY?
I mean if the values where wrong, arguments where insane or whatever then PF should happen in both elf and binary format.
Is not it like that?
Here the elf is running OK.

please comment!

[Combuster]

As a good C programmer you should know that broken pointers have the weirdest of symptoms, that can be changed or (temporarily) fixed by changing completely unrelevant code. Changing between ELF and binary is one such should-not-matter change, so I highly recommend grabbing bochs debugger and check every bit for absolute correctness. There's hardly a point in continuously poking us around for a hundred and one possible solutions since that costs all of us a lot more time.