multiboot module entry

[Mr. P]

Hello!
How do I get the entry point from a module that GRUB has loaded?

[Mr. P]

Or is GRUB loading the whole binary, with ELF-header and all?

[Solar]

Multiboot specification, the "Boot information format" chapter.

Code: Select all

The format of the Multiboot information structure (as defined so far) follows:

             +-------------------+
     0       | flags             |    (required)
             +-------------------+
     4       | mem_lower         |    (present if flags[0] is set)
     8       | mem_upper         |    (present if flags[0] is set)
             +-------------------+
     12      | boot_device       |    (present if flags[1] is set)
             +-------------------+
     16      | cmdline           |    (present if flags[2] is set)
             +-------------------+
     20      | mods_count        |    (present if flags[3] is set)
     24      | mods_addr         |    (present if flags[3] is set)
             +-------------------+
     28 - 40 | syms              |    (present if flags[4] or
             |                   |                flags[5] is set)
             +-------------------+
     44      | mmap_length       |    (present if flags[6] is set)
     48      | mmap_addr         |    (present if flags[6] is set)
             +-------------------+
     52      | drives_length     |    (present if flags[7] is set)
     56      | drives_addr       |    (present if flags[7] is set)
             +-------------------+
     60      | config_table      |    (present if flags[8] is set)
             +-------------------+
     64      | boot_loader_name  |    (present if flags[9] is set)
             +-------------------+
     68      | apm_table         |    (present if flags[10] is set)
             +-------------------+
     72      | vbe_control_info  |    (present if flags[11] is set)
     76      | vbe_mode_info     |
     80      | vbe_mode          |
     82      | vbe_interface_seg |
     84      | vbe_interface_off |
     86      | vbe_interface_len |
             +-------------------+
    
...

If bit 3 of the flags is set, then the mods fields indicate to the kernel what boot modules were loaded along with the kernel image, and where they can be found. mods_count contains the number of modules loaded; mods_addr contains the physical address of the first module structure. mods_count may be zero, indicating no boot modules were loaded, even if bit 1 of flags is set. Each module structure is formatted as follows:

             +-------------------+
     0       | mod_start         |
     4       | mod_end           |
             +-------------------+
     8       | string            |
             +-------------------+
     12      | reserved (0)      |
             +-------------------+
     

The first two fields contain the start and end addresses of the boot module itself. The string field provides an arbitrary string to be associated with that particular boot module; it is a zero-terminated ASCII string, just like the kernel command line. The string field may be 0 if there is no string associated with the module. Typically the string might be a command line (e.g. if the operating system treats boot modules as executable programs), or a pathname (e.g. if the operating system treats boot modules as files in a file system), but its exact use is specific to the operating system. The reserved field must be set to 0 by the boot loader and ignored by the operating system. 

Ergo, something you should have come across when you read the GRUB documentation... you did read the documentation before asking, did you?

[Mr. P]

Of course I did, I managed to load some modules but I didn't know how to interpret the data...

[Pype.Clicker]

afaik, GRUB does nothing special with the module. It simply loads it in memory, but i don't think it interpretes the ELF format for relocating, linking etc.

the fact BI has uses "binary" modules in "blue illusion" comforts me in this ... Similarily, The Mobius has DLL modules and does "mod = PeLoad(&proc_idle, temp, 0);" at some point (thus processing Protected Executable format within the kernel).

[durand]

Yeah, GRUB does nothing special with the module. It's just loaded into memory. You can load ELF, PE, binary, COM files and GRUB won't complain because it doesn't do anything with it.

It's up to your kernel to look at the data and interpret it as it sees fit - probably parsing the ELF header and building up the application image in order to run it.