grub-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: ELF bugfixes


From: Robert Millan
Subject: Re: ELF bugfixes
Date: Fri, 13 Mar 2009 20:14:42 +0100
User-agent: Mutt/1.5.18 (2008-05-17)

On Wed, Mar 11, 2009 at 10:21:41PM +0100, phcoder wrote:
> Robert Millan wrote:
>> On Mon, Mar 02, 2009 at 01:35:06AM +0100, phcoder wrote:
>>> +   * include/grub/elf.h: added missing attributes
>>
>> This should be a bit more descriptive.
>>
>>>    for (i = 0; i < ehdr->e_phnum; i++)
>>>      if (phdr(i)->p_type == PT_LOAD && phdr(i)->p_filesz != 0)
>>>        {
>>> -   if (phdr(i)->p_paddr < phdr(lowest_segment)->p_paddr)
>>> +   if (lowest_segment == -1 +          || phdr(i)->p_paddr < 
>>> phdr(lowest_segment)->p_paddr)
>>>       lowest_segment = i;
>>> -   if (phdr(i)->p_paddr > phdr(highest_segment)->p_paddr)
>>> +   if (highest_segment == -1
>>> +       || phdr(i)->p_paddr > phdr(highest_segment)->p_paddr)
>>>       highest_segment = i;
>>>        }
>>
>> Why?
>
> Because if first segment doesn't have the PT_LOAD attribute set then it  
> should be considered in this comparison

But you didn't remove the PT_LOAD check.  And in the routine below that
does the actual segment load, we still check for PT_LOAD.  Those should be
consistent, right?

>>> -  grub_multiboot_payload_entry_offset = ehdr->e_entry - 
>>> phdr(lowest_segment)->p_vaddr;
>>> +  grub_multiboot_payload_entry_offset = ehdr->e_entry - 
>>> phdr(lowest_segment)->p_paddr;
>>
>> Are you sure about this?  IIRC e_entry is in the virtual address space.  I
>> think we had some trouble with this (with NetBSD?), which lead to the current
>> use of p_vaddr in this line.
>>
> Actually now thinking I see that the problem is more deep. The section  
> which is loaded at the lowest address isn't necessarily the section  
> which contains entry point. I'll fix this part cleanly and will resubmit  
> the patch

No, but AFAICT the entry point is defined relative to that address, regardless
of which segment contains it.

-- 
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."




reply via email to

[Prev in Thread] Current Thread [Next in Thread]