From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22263 invoked by alias); 28 Aug 2010 13:39:42 -0000 Received: (qmail 22253 invoked by uid 22791); 28 Aug 2010 13:39:41 -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 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; Sat, 28 Aug 2010 13:39:38 +0000 Received: by vws16 with SMTP id 16so4779560vws.0 for ; Sat, 28 Aug 2010 06:39:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.220.128.68 with SMTP id j4mr1327868vcs.208.1283002776778; Sat, 28 Aug 2010 06:39:36 -0700 (PDT) Received: by 10.220.78.193 with HTTP; Sat, 28 Aug 2010 06:39:36 -0700 (PDT) In-Reply-To: <20100828132836.GY15723@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> Date: Sat, 28 Aug 2010 17:25: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/msg00362.txt.bz2 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. You can't depend on contents in p_addr in objcopy. > 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->header_s= ize > =A0 =A0 =A0 =A0from lowest_section, not first_section. =A0Validate program > =A0 =A0 =A0 =A0header p_paddr against section lma. =A0Find lowest_section= in > =A0 =A0 =A0 =A0second loop over headers. > Can we not look at p_addr here? --=20 H.J.