Get the value "text-and-data" from grub

[gedd]

Hi,
as you can see in the picture grub display an information "text-and-data" which is the size of the loaded kernel in memory.
How to get this information that is not present in multiboot information structure ?

Thanks

grub.png

[Combuster]

Grub prints information of the ELF header, that's where you should get your data from: put a reference to the end of the image in your code, and your linker script. If you used the barebones' script, you can use this:

Code: Select all

extern char sbss; // first byte in the BSS section 
(...)
intptr_t image_end = (intptr_t)&sbss; // address where BSS starts, and thus where .text and .data ends

[gedd]

As it can be seen on the picture (but not be readed in the text ), i have no ELF header because my kernel is a PE file.
And because i use VS2008 i have not LD script of course so i don't use barebones'script but the excellent Booting non-ELF kernel with GRUB tutorial

To impliment my physical memory manager i must know the kernel size, so grub know and display it but don't provide info if not ELF or a.out format

[AJ]

Hi,

1. Parse the PE headers,
2. Find a way of sticking markers at the start and end of your kernel (same idea as the linker script), or...
3. Use an Elf GCC Cross-Compiler.

Cheers,
Adam

[gedd]

1 & 2 are the way i was thinking
3 : no way for different reasons

Thanks

In fact the easiest way was to ask it to Grub because he had the information.
I'll see in grub source maybe ...

[Combuster]

Grub knows the filesize, that's it...

[neon]

IMAGE_OPTIONAL_HEADER->SizeOfImage is what you want. Its easy to write a generic PE getFileSize routine that the kernel can use.

[gedd]

IMAGE_OPTIONAL_HEADER->SizeOfImage is what you want. Its easy to write a generic PE getFileSize routine that the kernel can use.

Yes like that :

Code: Select all

 PartialMSDOS_HEADER *dh = (PartialMSDOS_HEADER *)LOADBASE;
NT_Header *nth = (NT_Header *)(dh->PEHeaderOffset + LOADBASE);
int iKernelSize = nth->OptionalHeader.SizeOfImage;

The information seems to be missing in the Grub multiboot info for non elf or a.out kernel.

[quok]

The information seems to be missing in the Grub multiboot info for non elf or a.out kernel.

Of course it is. As has been pointed out already, and is painfully obvious if you bother to read the multiboot spec at all, GRUB only knows the ELF format. The a.out kludge is provided so that GRUB can load and properly zero the BSS section of any other kind of binary file, such as COFF or even PE (which you are constantly complaining about). If you'd properly fill in the values in the a.out kludge structure then perhaps you'd have much better luck here. As it is, GRUB doesn't even know about your BSS section so isn't bothering to zero it for you. I hope you're able to do that yourself, although it's much easier to just tell GRUB where it is and how big it is.

As it can be seen on the picture (but not be readed in the text ), i have no ELF header because my kernel is a PE file.
And because i use VS2008 i have not LD script of course so i don't use barebones script but the excellent Booting non-ELF kernel with GRUB tutorial

I'd hardly call that an "excellent tutorial" if it doesn't cover half the things you need to know, like how to get the size of the kernel loaded in memory.

From your own tutorial:

Code: Select all

multiboot_header:
    dd(MULTIBOOT_HEADER_MAGIC)      ; magic number
    dd(MULTIBOOT_HEADER_FLAGS)      ; flags
    dd(CHECKSUM)               ; checksum
    dd(HEADER_ADRESS)            ; header address
    dd(LOADBASE)               ; load address
    dd(00)                     ; load end address : not used
    dd(00)                     ; bss end addr : not used
    dd(HEADER_ADRESS + 0x20)      ; entry_addr : equ kernel entry      
                                    ; 0x20 is the size of multiboot heeader

Are you stupid, or just lazy? Actually, nevermind; I don't want to know. Either one isn't a proper excuse.

You've been given proper answers to this "question" of yours already. I've just given you another. Pick something and implement it. If you can't be bothered to learn how to properly use your compiler toolchain (which seems to be the case), you've broken forum rule #3. As far as I'm concerned, you also broke rule #4.

Since GRUB doesn't work for you, perhaps you should just extend it so that it does, or write a bootloader yourself to make sure you get absolutely everything you want in a bootloader. GRUB isn't for everyone, but at least most people here follow the advice they are given and move on, rather than complaining about the same old crap day in and day out.