From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LiGNZ-0005wm-Iq for mharc-grub-devel@gnu.org; Fri, 13 Mar 2009 19:01:25 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LiGNX-0005w7-MD for grub-devel@gnu.org; Fri, 13 Mar 2009 19:01:23 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LiGNS-0005t9-Fs for grub-devel@gnu.org; Fri, 13 Mar 2009 19:01:22 -0400 Received: from [199.232.76.173] (port=45287 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LiGNS-0005t1-9b for grub-devel@gnu.org; Fri, 13 Mar 2009 19:01:18 -0400 Received: from fk-out-0910.google.com ([209.85.128.191]:38887) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LiGNR-0005kd-8J for grub-devel@gnu.org; Fri, 13 Mar 2009 19:01:17 -0400 Received: by fk-out-0910.google.com with SMTP id 19so1304205fkr.10 for ; Fri, 13 Mar 2009 16:01:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:received:received:message-id:date:from :user-agent:mime-version:to:subject:references:in-reply-to :content-type:content-transfer-encoding; bh=v7Eb754y1fiZF7IFspRqwXCL5oO6UDlcfSQNhGx6WZs=; b=AF6fqetywJQdyRq7L+RuCEcYXepD+K14/WtArBlPiyM/CtSnDo60284lbAOi2ydGyO ELH1VKFwd8i9CgXOZ/Pbo0LmX9p3Z+BPv5DdSLZNZUO7x4ta8M7z/PmN9rCUrGJ9M7Gr A6tdlZ9F6qui+MdhkAgg17Qsekr3RORKB0rG0= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=message-id:date:from:user-agent:mime-version:to:subject:references :in-reply-to:content-type:content-transfer-encoding; b=u3c/LWxb9lKtQVl8EAEUaFRWWR+BsQ/i2sDPDcGSFM38Uoxey+aI3AjiWLwU2ut2f8 n6u57HG+YMeobFs2rZeWbItFJteNGyIv1i5QuXCUiprNw1bv8IoLpQDuj2EVDchXQ1g9 juo5HvUKQsDQyxRObS/oAmigoifxC9qWEeHrQ= Received: by 10.103.226.10 with SMTP id d10mr873154mur.35.1236985275597; Fri, 13 Mar 2009 16:01:15 -0700 (PDT) Received: from ?192.168.1.25? (7.86.202.62.cust.bluewin.ch [62.202.86.7]) by mx.google.com with ESMTPS id u26sm4683045mug.58.2009.03.13.16.01.14 (version=SSLv3 cipher=RC4-MD5); Fri, 13 Mar 2009 16:01:15 -0700 (PDT) Message-ID: <49BAE5B9.4020303@gmail.com> Date: Sat, 14 Mar 2009 00:01:13 +0100 From: phcoder User-Agent: Thunderbird 2.0.0.19 (X11/20090105) MIME-Version: 1.0 To: The development of GRUB 2 References: <49AB29BA.6040609@gmail.com> <20090311211541.GC29956@thorin> <49B82B65.3080506@gmail.com> <20090313191442.GC17068@thorin> <49BAC506.2030006@gmail.com> <20090313224629.GA781@thorin> In-Reply-To: <20090313224629.GA781@thorin> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-detected-operating-system: by monty-python.gnu.org: GNU/Linux 2.6 (newer, 2) Subject: Re: ELF bugfixes X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list Reply-To: The development of GRUB 2 List-Id: The development of GRUB 2 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 13 Mar 2009 23:01:24 -0000 Robert Millan wrote: > On Fri, Mar 13, 2009 at 09:41:42PM +0100, phcoder wrote: >> Robert Millan wrote: >>> 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? >>> >> No I expressed myself badly. Original code assumed that first segment >> has PT_LOAD always set (lowest_segment is 0 initally). I removed this >> assumption > > Why do we care about non-PT_LOAD segments? We don't but without this fix non-PT_LOAD segment 1 wasn't correctly ignored > >>>>>> - 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. >>> >> Actually our segment table is also our table for transforming between >> virtual and physical address. I don't see why entry point would be >> defined against virtual address of lowest physical segement > > I think entry point is supposed to be defined in virtual address space. As > to why do we check for physical addresses earlier, I'm not entirely sure. I > think the idea was that we store the entry point as an offset, so that it > can be applied to physical addresses, despite the fact that we obtained it > by comparing e_entry with a virtual address. > > ISTR this being an issue for NetBSD. We should be certain what we do before > changing it. In particular, the following commit seem relevant: > > 2008-02-05 Bean > > * loader/i386/pc/multiboot.c (grub_multiboot_load_elf32): Get physical > address of entry. > > I'd also recommend testing your changes with NetBSD's kernel. > Ok will do it -- Regards Vladimir 'phcoder' Serbinenko