From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with archive (Exim 4.43) id 1LiECZ-0004Qd-MD for mharc-grub-devel@gnu.org; Fri, 13 Mar 2009 16:41:55 -0400 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1LiECY-0004P3-3w for grub-devel@gnu.org; Fri, 13 Mar 2009 16:41:54 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1LiECS-0004Or-Mn for grub-devel@gnu.org; Fri, 13 Mar 2009 16:41:52 -0400 Received: from [199.232.76.173] (port=49833 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1LiECS-0004Oo-Hc for grub-devel@gnu.org; Fri, 13 Mar 2009 16:41:48 -0400 Received: from mail-fx0-f176.google.com ([209.85.220.176]:38002) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1LiECR-0001hv-V3 for grub-devel@gnu.org; Fri, 13 Mar 2009 16:41:48 -0400 Received: by fxm24 with SMTP id 24so2935958fxm.42 for ; Fri, 13 Mar 2009 13:41:46 -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=LaxIoK31QVrzlibg0unAtYcl/fQBmJBlx8eSbGKoNQs=; b=bQsI4lJwEdoBIN65HG+XvKeSjl7TAp4CFRZm//PlLetOCTqK21w4wJN6D1K1cXZ8ZD 5C/1BQ6UIQIdDvhiMiKe/jJGbvAVPHu5y8nw4lzFxk6vM2keS0UwMj1PSfrM+IzuS4a7 UKITCZ5hmGDS4ZOUtj7t9NcCU59gDh0q21sWg= 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=jdNtuqL2KkxUCiR22dTnsXmRAKOdxb9aKyUPRYUJSlUyfwnBirWkS7US6wYmw+1HNv t7p9QXVQjHH1v7fczR/z0Q7baQXJjf40BXamNzbmpQ7wtjsrVhtNKt+PjZzGZd+yO6N+ 5g4yij6em7JkMROA0f0yi8ScKhdl5uBnV9zYs= Received: by 10.103.102.17 with SMTP id e17mr852749mum.119.1236976905914; Fri, 13 Mar 2009 13:41:45 -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 w5sm4422107mue.33.2009.03.13.13.41.44 (version=SSLv3 cipher=RC4-MD5); Fri, 13 Mar 2009 13:41:45 -0700 (PDT) Message-ID: <49BAC506.2030006@gmail.com> Date: Fri, 13 Mar 2009 21:41:42 +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> In-Reply-To: <20090313191442.GC17068@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 20:41:54 -0000 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 >>>> - 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 -- Regards Vladimir 'phcoder' Serbinenko