I don't think that the fact that this is fixed in NetBSD means that the problem in GRUB Legacy has gone away.  The bug is still there and should be fixed, if at all possible.

It is a different issue if you don't want to fix it because the code is "dead"... but, in that case, please state so :-)

Sorry but the first patch had a problem.  It didn't properly reserve space for the BSS section, so the symbol table was copied into BSS space and destroyed during the kernel's boot.

I've fixed this in the new patch by making GRUB put the symbol table after the BSS space, if any.  (And now NetBSD properly loads the symbols :-)

The Multiboot header defines a set of fields that can be used to tell the boot loader where to load a kernel image.  These fields must be specified when loading an a.out image, in which case they are properly used by GRUB.  However, when the image is an ELF file, these fields are optional and unfortunately GRUB does not honour them.

This makes it impossible to load a Multiboot kernel which is mapped to a very high virtual memory address, because GRUB will always spit out a "ERR_WONT_FIT" error.

In my specific case, I've adapted the NetBSD kernel to be Multiboot-compliant.  NetBSD is built to be executed at the 0xc0100000 virtual address.  However, the kernel must be loaded at a lower address (0x00100000) because it relocates itself later on.  If you look at the code in GRUB to boot NetBSD kernels natively, you'll see how it "truncates" the addresses in the ELF file by doing an (& 0xFFFFFF).

If GRUB honoured the address fields in the Multiboot header, I'd use them to explicitly tell it where to place the kernel.