> > starting your own toy kernel is a fun thing to do and there are many > > tutorials out there on how to do it. Unfortunately when one wants to > > write a kernel in 64bit it becomes much harder because one can't > > compile 64bit code as elf32 image and converting a elf64 image to > > elf32 format is a major hassle and looses debug information and symbols.
So just have two versions of your image: - The elf64 image that has debug info, symbols, etc. Point gdb at this. - An elf32 image that you give to the bootloader (in this case kvm) Generating the latter from the former is a trivial objcopy invocation. The bootloader variant only needs enough information to get the loadable sections into memory. We don't care about non-resident clutter like debug info or symbols. Anything that cares about those will be using the full elf64 image. This is all standard practice. I don't think I've never actually used a system where the image loaded by the target is the same file as the one that comes out of the linker and is used by the debugger. > Yes, this is why I asked about support in other software. If each > bootloader implements a different custom method then it will be a pain > to run your binary on real hardware in the future. It's worth at > least checking their source first - maybe there is already a similar > code path that we can be compatible with, hence making life easier for > developers who want to play with 64-bit payloads in multiboot > executables. The whole idea of entering a 64-bit image in 32-bit mode seems distinctly sketchy. Surely it'd make more sense to define a 64-bit multiboot variant and do the job properly. Paul
