From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1Lixup-000533-RV for mharc-grub-devel@gnu.org; Sun, 15 Mar 2009 17:30:39 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Lixun-00052y-N2 for grub-devel@gnu.org; Sun, 15 Mar 2009 17:30:37 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1Lixuh-0004yq-U3 for grub-devel@gnu.org; Sun, 15 Mar 2009 17:30:36 -0400 Received: from [199.232.76.173] (port=33567 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Lixuh-0004yn-Pm for grub-devel@gnu.org; Sun, 15 Mar 2009 17:30:31 -0400 Received: from fk-out-0910.google.com ([209.85.128.184]:34028) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1Lixuh-0002ih-AZ for grub-devel@gnu.org; Sun, 15 Mar 2009 17:30:31 -0400 Received: by fk-out-0910.google.com with SMTP id 19so1497369fkr.10 for ; Sun, 15 Mar 2009 14:30:29 -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=RIytbW4YB+ATrb04C9PpKsQTBD9/ZbVwQy2z/w1j8+c=; b=jYEJhdbu4G93NRa8bRlIkKJmYOFxDQlUo0Erqh62qJkOTULTeivLMl60UbaYpndUeu H0juyti8VpBx328erAkdjFRykS/PBWvAS0hxaugFSiShQHzQdJ43D+Lefi78oj0pvAXy MU1s3eSgb3WBBSjJqHiwdfanvHA1839x11YWg= 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=liM1rxP+F7SjLC76JYo51fEsd2FdcL80/upjHw8T3zvYFMrI6f7VtYXJkKtCdHOznl antn9WGrGmcMdIr2r5WHCr07VWicrgnHamztWmkJeaeBP2rXqmQ0ipmYRZuGnZ2JMCff sgbOqjfTHaNndx/sRCcKUnO+SsH6SEeEi33Tg= Received: by 10.103.92.8 with SMTP id u8mr1780049mul.34.1237152629442; Sun, 15 Mar 2009 14:30:29 -0700 (PDT) Received: from ?192.168.1.2? (177-25.3-85.cust.bluewin.ch [85.3.25.177]) by mx.google.com with ESMTPS id i5sm8809487mue.13.2009.03.15.14.30.28 (version=SSLv3 cipher=RC4-MD5); Sun, 15 Mar 2009 14:30:28 -0700 (PDT) Message-ID: <49BD7374.10500@gmail.com> Date: Sun, 15 Mar 2009 22:30:28 +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: Sun, 15 Mar 2009 21:30:38 -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? > >>>>>> - 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. > Tested. Works fine -- Regards Vladimir 'phcoder' Serbinenko