OSDev.org

Hi,
I have one question? Can I use Multiboot1 with x86_64 kernel? If so, can it use with ELF64? I want to writing debug utilities with stack trace, but Multiboot2 is too complicated for me

Multiboot 2 is not complicated. I strongly recommend it over Multiboot 1. I've also tried to start with Multiboot 1, but I met a lot of problems. I don't remember what kind of problems (this was more than a year ago), but at least with Multiboot 2 everything works great. Multiboot 1 & 2 are very similar for the most basic tasks. The main difference is how data is organized in memory. Multiboot 2 uses tags, which are placed in memory after the header. The common pitfall is that tags are aligned, so they may have some gaps between them. However it is not hard to parse them.

Also you can try my auxiliary library for kernel development (https://github.com/tailix/libkernaux). It includes Multiboot 2 parser. Unfortunatelly it's not well documented, examples are missing, and the API for Multiboot 2 parser will change soon.

kotovalexarian wrote:Multiboot 2 is not complicated. I strongly recommend it over Multiboot 1. I've also tried to start with Multiboot 1, but I met a lot of problems. I don't remember what kind of problems (this was more than a year ago), but at least with Multiboot 2 everything works great. Multiboot 1 & 2 are very similar for the most basic tasks. The main difference is how data is organized in memory. Multiboot 2 uses tags, which are placed in memory after the header. The common pitfall is that tags are aligned, so they may have some gaps between them. However it is not hard to parse them.

Also you can try my auxiliary library for kernel development (https://github.com/tailix/libkernaux). It includes Multiboot 2 parser. Unfortunatelly it's not well documented, examples are missing, and the API for Multiboot 2 parser will change soon.

Thank you.

Yes, you can use Multiboot1 for a x86_64 kernel.

mid wrote:Yes, you can use Multiboot1 for a x86_64 kernel.

Oh, thank you.

NeonLightions wrote:

mid wrote:Yes, you can use Multiboot1 for a x86_64 kernel.

Oh, thank you.

Wait, there's still one question: Can I use it with ELF64?

Ye, GRUB works with ELF64. I'm not sure if that's actually in the multiboot spec, however.

By the way, I have post my code on stack tracing to my repo. It just catch 1 function name and stop. Can anyone help me solve this?

Multiboot1 will always drop you off in a 32-bit environment. If you can write a 32-bit entry point in assembler that manages to prepare all the paging structures you require and switches to 64-bit mode before running any C function, then yes, you can use multiboot1. I personally have chosen to implement multiboot1 for my 64-bit kernel by using the module mechanism: I have written a small 32-bit "kernel" that takes the actual 64-bit kernel as a module (and requests page alignment of all modules). And then just creates the paging structures the main kernel requires, and formats the multiboot information in a kernel-specific way, and then it just launches the 64-bit kernel.

This is done so that I can also have a UEFI bootloader independent of the multiboot loader, and run my kernel on both UEFI and legacy machines. However, if you are creating a 64-bit kernel, then the number of machines not able to run a UEFI application is minuscule compared the number of those that are, so the UEFI application is almost certainly more important than the multiboot application. I would therefore suggest you look into creating one of those and find an emulator that allows you to run UEFI applications, or a way to configure your emulator to do so.

NeonLightions wrote:Can anyone help me solve this?

Please, make your question more specific and give a link to your code.

kotovalexarian wrote:

NeonLightions wrote:Can anyone help me solve this?

Please, make your question more specific and give a link to your code.

I'm sorry, I forgot to give you my repo, here is it: https://github.com/NeonLightions/Amore-OS-x64
Also, I want to have a back trace mechanism like Python. It will take return address in stack frames, look for symbol name in ELF symbol table and print it into screen.

As I understand right even multiboot2 leaves you in protected mode(32bit). And you need to switch to long mode(64bit) by yourself.

NeonLightions wrote:Also, I want to have a back trace mechanism like Python. It will take return address in stack frames, look for symbol name in ELF symbol table and print it into screen.

That's a nice idea. I also feel the need in such mechanism. I have not idea how to achieve this, but I'll take a look.

kotovalexarian wrote:

NeonLightions wrote:Also, I want to have a back trace mechanism like Python. It will take return address in stack frames, look for symbol name in ELF symbol table and print it into screen.

That's a nice idea. I also feel the need in such mechanism. I have not idea how to achieve this, but I'll take a look.

Thanks, I'm looking forward to it.

Here is some stack tracing example: https://github.com/josehu07/hux-kernel/ ... -&-Testing