From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18631 invoked by alias); 30 Aug 2010 04:46:30 -0000 Received: (qmail 18614 invoked by uid 22791); 30 Aug 2010 04:46:26 -0000 X-SWARE-Spam-Status: No, hits=-1.8 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,TW_BJ,TW_JC X-Spam-Check-By: sourceware.org Received: from mail-vw0-f41.google.com (HELO mail-vw0-f41.google.com) (209.85.212.41) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 30 Aug 2010 04:46:15 +0000 Received: by vws16 with SMTP id 16so5936528vws.0 for ; Sun, 29 Aug 2010 21:46:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.62.72 with SMTP id w8mr2494793vch.172.1283143573429; Sun, 29 Aug 2010 21:46:13 -0700 (PDT) Received: by 10.220.78.193 with HTTP; Sun, 29 Aug 2010 21:46:13 -0700 (PDT) In-Reply-To: <20100830032012.GZ15723@bubble.grove.modra.org> References: <4D60B0700D1DB54A8C0C6E9BE69163700E67DFD1@EXCHANGEVS.IceraSemi.local> <20100421082441.GG3510@bubble.grove.modra.org> <4D60B0700D1DB54A8C0C6E9BE69163700E7815C7@EXCHANGEVS.IceraSemi.local> <20100422011106.GI3510@bubble.grove.modra.org> <20100422015303.GK3510@bubble.grove.modra.org> <20100828105631.GW15723@bubble.grove.modra.org> <20100828132836.GY15723@bubble.grove.modra.org> <20100830032012.GZ15723@bubble.grove.modra.org> Date: Mon, 30 Aug 2010 05:11:00 -0000 Message-ID: Subject: Re: VMA section overlap warnings for overlays From: "H.J. Lu" To: "H.J. Lu" , binutils@sourceware.org Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2010-08/txt/msg00366.txt.bz2 On Sun, Aug 29, 2010 at 8:20 PM, Alan Modra wrote: > On Sat, Aug 28, 2010 at 06:39:36AM -0700, H.J. Lu wrote: >> On Sat, Aug 28, 2010 at 6:28 AM, Alan Modra wrote: >> > The real bug was that copy_elf_program_header calculated header_size >> > from the first section found to be in the segment rather than the >> > section with the lowest lma. =A0So a one line fix. =A0The rest of this >> > patch is to cope with (and fix) invalid program header p_paddr values. >> >> There is no such a thing as "invalid program header p_paddr values" >> since ELF spec says it has unspecified contents. > > Yes, that's technically true. =A0My language wasn't precise. =A0I should > have said inconsistent p_paddr values. > >> You can't depend on contents in p_addr in objcopy. > > Are you saying that objcopy should throw away all p_paddr values? > That doesn't make sense at all. =A0Just because the ELF spec doesn't > specify p_paddr, doesn't mean that GNU binutils cannot use p_paddr. > We use p_paddr to record section LMAs, since ELF section headers only > have a field for VMAs. > >> > I won't commit this immediately as I'd like to run some more tests. >> > >> > =A0 =A0 =A0 =A0PR binutils/11953 >> > =A0 =A0 =A0 =A0* elf.c (copy_elf_program_header): Calculate map->heade= r_size >> > =A0 =A0 =A0 =A0from lowest_section, not first_section. =A0Validate pro= gram >> > =A0 =A0 =A0 =A0header p_paddr against section lma. =A0Find lowest_sect= ion in >> > =A0 =A0 =A0 =A0second loop over headers. >> > >> >> Can we not look at p_addr here? > > I don't know what you mean by that question. > Can we compute p_addr from other fields and don't check if it matches the original value? --=20 H.J.