From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 31717 invoked by alias); 11 Oct 2010 14:44:11 -0000 Received: (qmail 31706 invoked by uid 22791); 11 Oct 2010 14:44:10 -0000 X-SWARE-Spam-Status: No, hits=-2.1 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 11 Oct 2010 14:44:05 +0000 Received: (qmail 29305 invoked from network); 11 Oct 2010 14:44:03 -0000 Received: from unknown (HELO caradoc.them.org) (dan@127.0.0.2) by mail.codesourcery.com with ESMTPA; 11 Oct 2010 14:44:03 -0000 Date: Mon, 11 Oct 2010 14:44:00 -0000 From: Daniel Jacobowitz To: Matt Fischer Cc: binutils@sourceware.org Subject: Re: Load addresses for ELF program headers on ARM Message-ID: <20101011144357.GA1024@caradoc.them.org> Mail-Followup-To: Matt Fischer , binutils@sourceware.org References: <20101011015506.GM26553@bubble.grove.modra.org> <20101011032919.GP26553@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) 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-10/txt/msg00166.txt.bz2 On Sun, Oct 10, 2010 at 10:38:59PM -0500, Matt Fischer wrote: > On Sun, Oct 10, 2010 at 10:29 PM, Alan Modra wrote: > > On Sun, Oct 10, 2010 at 09:43:27PM -0500, Matt Fischer wrote: > >> However, when I do this, it creates one gigantic segment which has > >> both sections at their relocation addresses, and zero-fills the 200MB > >> or so in between them.  It seems like the linker is not correctly > >> respecting load addresses when it tries to fit sections into segments. > >>  Is that something that can be gotten around somehow? > > > > This is a 2.20 bug.  With current mainline you'll get a warning > >  section `DATA' can't be allocated in segment 0 > > but ld will place DATA immediately after TEXT in the segment.  The > > warning is because the VMA for DATA is outside the virtual addresses > > covered by your program header.  (The warning should probably say > > something to that effect rather than "can't be allocated" when the > > section *is* allocated there.) > > Ah, excellent. Ok, so I'll just patch the binaries for now, and then > pick up that change once it's available. Dan, any idea when that fix > will make its way into Sourcery Lite? A bit off topic for this list but... If this fix is in assign_file_positions_for_load_sections, which I think it is, then it will be in our November releases. -- Daniel Jacobowitz CodeSourcery