On Sat, Mar 21, 2009 at 07:05:23PM +0100, phcoder wrote: > Robert Millan wrote: >> On Sat, Mar 21, 2009 at 06:58:58PM +0100, phcoder wrote: >>> Robert Millan wrote: >>>> On Wed, Mar 18, 2009 at 02:26:40PM +0100, phcoder wrote: >>>>> Robert Millan wrote: >>>>>> On Fri, Mar 13, 2009 at 09:52:39PM +0100, phcoder wrote: >>>>>>> - grub_multiboot_payload_entry_offset = ehdr->e_entry - >>>>>>> phdr(lowest_segment)->p_vaddr; >>>>>>> + for (i = 0; i < ehdr->e_phnum; i++) >>>>>>> + if (phdr(i)->p_vaddr <= ehdr->e_entry + && >>>>>>> phdr(i)->p_vaddr + phdr(i)->p_memsz > ehdr->e_entry) >>>>>>> + grub_multiboot_payload_entry_offset = (ehdr->e_entry - >>>>>>> phdr(i)->p_vaddr) >>>>>>> + + (phdr(i)->p_paddr - phdr(lowest_segment)->p_paddr); >>>>>> You need to handle the case in which grub_multiboot_payload_entry_offset >>>>>> is left >>>>>> uninitialized (it needs to be initialized each time the multiboot >>>>>> command is >>>>>> run, not just when the module is loaded). >>>>>> >>>>> module? actually it's when loading image. Perhaps you mean that >>>>> additional error check is necessary >>>> I meant GRUB's multiboot.mod, not the payload's module. Sorry I wasn't >>>> clear. >>>> >>> With this error check if grub_multiboot_payload_entry_offset it can >>> happen only if no image is loaded. And actually >>> grub_multiboot_payload_entry_offset is set to 0 at multiboot.mod load >>> So I don't really understand the problem >> >> You can't rely on grub_multiboot_payload_entry_offset being set to 0, because >> any subsequent call of "multiboot /something" has the potential to override >> this. You must not assume the multiboot command is only going to be run >> once. >> > No but it always corresponds to the current image. It's set either in > multiboot.c or in grub_multiboot_load_elf
It is now, but your code makes this conditional. -- Robert Millan The DRM opt-in fallacy: "Your data belongs to us. We will decide when (and how) you may access your data; but nobody's threatening your freedom: we still allow you to remove your data and not access it at all." _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org http://lists.gnu.org/mailman/listinfo/grub-devel
