From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18204 invoked by alias); 30 Aug 2010 03:20:26 -0000 Received: (qmail 18195 invoked by uid 22791); 30 Aug 2010 03:20:25 -0000 X-SWARE-Spam-Status: No, hits=-1.9 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-px0-f169.google.com (HELO mail-px0-f169.google.com) (209.85.212.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 30 Aug 2010 03:20:20 +0000 Received: by pxi5 with SMTP id 5so3861222pxi.0 for ; Sun, 29 Aug 2010 20:20:19 -0700 (PDT) Received: by 10.114.124.18 with SMTP id w18mr2400250wac.207.1283138419345; Sun, 29 Aug 2010 20:20:19 -0700 (PDT) Received: from bubble.grove.modra.org ([115.187.252.19]) by mx.google.com with ESMTPS id o17sm7064304wal.9.2010.08.29.20.20.16 (version=TLSv1/SSLv3 cipher=RC4-MD5); Sun, 29 Aug 2010 20:20:17 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 1E42B170C1F1; Mon, 30 Aug 2010 12:50:12 +0930 (CST) Date: Mon, 30 Aug 2010 04:46:00 -0000 From: Alan Modra To: "H.J. Lu" Cc: binutils@sourceware.org Subject: Re: VMA section overlap warnings for overlays Message-ID: <20100830032012.GZ15723@bubble.grove.modra.org> Mail-Followup-To: "H.J. Lu" , binutils@sourceware.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> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) 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/msg00365.txt.bz2 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.  So a one line fix.  The 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. My language wasn't precise. I 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. Just 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. > > > >        PR binutils/11953 > >        * elf.c (copy_elf_program_header): Calculate map->header_size > >        from lowest_section, not first_section.  Validate program > >        header p_paddr against section lma.  Find lowest_section in > >        second loop over headers. > > > > Can we not look at p_addr here? I don't know what you mean by that question. -- Alan Modra Australia Development Lab, IBM