INT6 when trying to load GRUB module

[pieman2201]

First post here, apologies if something is wrong.

I'm trying to load a GRUB module as a very simple program. However, when calling it I get an INT6 "Invalid Opcode" exception. Everything seems in order, however, and I don't know what I'm doing wrong. My code is below.

Here is the "program" which I compile into a flat binary:

Code: Select all

mov eax, 0xDEADBEEF
loop:
    jmp loop

Here is where I call my C code from Assembly:

Code: Select all

extern kmain
push ebx
call kmain

Here is where I attempt to call the program from my C code:

Code: Select all

#include "multiboot.h"

//including other stuff, functions, etc.

int kmain(unsigned int ebx){
    //load gdt, setup interrupts, etc.

    puts("Hello, world!");

    multiboot_info_t *mb_info = (multiboot_info_t *)ebx;
    void (*start_program)();

    unsigned int module_address = mb_info->mods_addr;
    unsigned int module_count = mb_info->mods_count;
    
    if (module_count == 1){
        start_program = (void *)module_address;
        start_program();
    }

    return 0;
}

If you need anything else I would be happy to supply it.
Any help is appreciated. Thanks!

[iansjack]

Here is the "program" which I compile into a flat binary

GRUB modules are Elf-format files, not flat binaries.

[BrightLight]

Undefined opcode exception is INT 6, not IRQ 6.

[iansjack]

You may want to read the following with regard to writing GRUB modules: http://blog.fpmurphy.com/2010/06/grub2- ... output=pdf

[pieman2201]

GRUB modules are Elf-format files, not flat binaries.

I'm using https://littleosbook.github.io/#loading ... al-program as an outline for this, and it says to make a flat binary. Is this wrong?

[pieman2201]

Undefined opcode exception is INT 6, not IRQ 6.

Apologies, corrected. Thanks.

[iansjack]

GRUB modules are Elf-format files, not flat binaries.

I'm using https://littleosbook.github.io/#loading ... al-program as an outline for this, and it says to make a flat binary. Is this wrong?

I must admit that I've never tried the procedure outlined in that book. I'd suggest that you single-step through the code to see where it hits the invalid opcode. It should then be fairly obvious what is going wrong.

But if you want to run a program in kernel mode, why load it as a GRUB module. Why not just compile it in as part of the kernel?

[Boris]

You are trying to read a multi boot module, not a grub module.

Multi boot modules can be anything . A binary, a zip file, or even a MP3.

If you are not doing a flat file, chances is you are trying to execute the start of an ELF file , which has a header starting with "ELF". You are trying to tell your CPU to execute an ASCII string.

Doing a flat binary removes any complicated part of the module , leaving only a valid stream for the CPU. It seems nice. But it has also restrictions :

* Your module has to be position independent . Because grub will put it at a random location. You are to use only relative addresses.
* Which means , it will be *VERy* difficult to create global variables in C.
* your module won't be able to access your kernel symbols, except if you manually give it pointers which you won't be able to store due to the lack of globals.

So, I would avoid doing flat binaries.

[pieman2201]

You are trying to read a multi boot module, not a grub module.

Multi boot modules can be anything . A binary, a zip file, or even a MP3.

If you are not doing a flat file, chances is you are trying to execute the start of an ELF file , which has a header starting with "ELF". You are trying to tell your CPU to execute an ASCII string.

Doing a flat binary removes any complicated part of the module , leaving only a valid stream for the CPU. It seems nice. But it has also restrictions :

* Your module has to be position independent . Because grub will put it at a random location. You are to use only relative addresses.
* Which means , it will be *VERy* difficult to create global variables in C.
* your module won't be able to access your kernel symbols, except if you manually give it pointers which you won't be able to store due to the lack of globals.

So, I would avoid doing flat binaries.

I know that flat binaries aren't a permanent solution, but I just wanted to try this out. Since something is broken, I'm trying to figure out why it doesn't work in order to prevent possibly having to fix a lot of stuff down the road.

[Combuster]

GRUB modules are Elf-format files, not flat binaries.

That is not true.

@item boot module
Other auxiliary files that a boot loader loads into memory along with
an OS image, but does not interpret in any way other than passing their
locations to the operating system when it is invoked.

[xenos]

GRUB modules are Elf-format files, not flat binaries.

That is not true.

Actually it is true: http://wiki.osdev.org/Writing_GRUB2_Modules
But the OP meant a multiboot module (which, as you correctly stated, can be anything), not a GRUB module (which is Elf).

[iansjack]

You're right, I took the OP at his word when he said he was trying to use a GRUB module. The article I linked to is clearly not applicable to his real requirements.