OSDev.org

Hi everyone,
consider the following example from gnu's official documentation about multiboot: https://www.gnu.org/software/grub/manua ... le-OS-code
In particular, look at the definition `struct multiboot_info` in `multiboot.h` and at the first table under "3.3 Boot information format".
Seemingly they fit well together and indeed, I was able to correctly draw some pixels on screen with the framebuffer for example. But isn't the struct automatically padded for alignment? If it's padded, then the addresses in the table won't match the offsets inside the struct, so if I do `mbi->framebuffer_addr` it will point to a higher address than where the framebuffer address actually resides. As far as I can see, the struct neither has the __attribute__((packed)) nor are the fields arranged in a way that wouldn't require padding.
What am I missing? I'm hoping I have a fundamental misunderstanding somewhere so I can learn about it.
Thanks in advance!

Why? framebuffer_addr is shown in the table to be at offset 88, which is divisible by 8, so no padding needs to be applied for a 64-bit number. There is no difference between having the packed attribute and not having it if everything is already aligned at natural boundaries.

Thanks for the answer. Yeah I agree about that address, but what about `framebuffer_palette_addr`? It's supposed to be at address 110 and has size 4 bytes. But address 110 is not 4 byte aligned. So there should be 2 bytes of padding before it. Maybe it has to do with it being part of a struct that's part of a union, but I don't see why that would make a difference. If the `color_info` space is interpreted as the second struct, there is no problem with alignment, but if it's interpreted as the first...

No, you are completely correct; that part can't work. framebuffer_palette_addr is defined as a 4-byte value, thereby raising the alignment requirement of every aggregate that contains it to at least 4. This also concerns the union containing everything, which means the compiler will insert two padding bytes after framebuffer_type. I was tempted to say they didn't test paletted modes too well, but this also means the color offsets for the direct color modes are also at offset 112. So either the spec is wrong here or the header file is. Thankfully we needn't speculate, as everything is open-source. Let me look up the grub2 sources real quick...

The grub2 sources contain the same header file, so they also have those two unannounced (and undocumented) padding bytes. So the spec is wrong there. The frame buffer palette address and the color offsets both start at offset 112.

Many thanks! Also great tip to just look at the source code, might save me in the future as well