On Tue, 14 Sep 1999, OKUJI Yoshinori wrote:
> I don't know who is responsible for the maintenance of the Multiboot
> standard (I assume Erich is the one, though), so which version is
> canonical is not clear. But I'd like you to work on the TeXinfo
> version, as it's easy to convert TeXinfo to HTML but the reverse is
> difficult.
Ok, fine. If it's not done today it'll be done next week; I'm away
from computers from Wednesday to Sunday.
> > Consider this situation: we have a kernel that is intended to run at
> > virtual address 0xc0000000. We link it for that address, and include a
> > small amount of hand-written code at the start of the image to set up
> > page tables, enable paging and jump at the real start of the code. As
> > far as the ELF headers are concerned the load address for the program
> > text is 0xc0000000, which will upset GRUB.
>
> I don't think so, because ELF has a member for physical address as
> well as one for virtual address. GRUB makes use of the physical
> address to load a kernel image, so it does not matter where the
> virtual address is. [This is the behavior of the current version of
> GRUB. Older versions misused the member for virtual address to
> determine where a kernel image is loaded.]
Ok, good point. I shall have to have a play with GNU ld to see whether
it can generate ELF files with different physical and virtual load
addresses.
The point that bit 16 is useless if it doesn't override ELF headers
still stands; we either have the situation where bit 16 and its
associated fields are ignored (which is pointless), or where they
aren't present but are required (which isn't terribly useful
either). Fixing GRUB so that it pays attention to bit 16 shouldn't
break any existing kernels.
Steve Early
