From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 1453 invoked by alias); 1 May 2003 21:37:11 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 1446 invoked from network); 1 May 2003 21:37:10 -0000 Received: from unknown (HELO mail-in.hq.tensilica.com) (65.205.227.29) by sources.redhat.com with SMTP; 1 May 2003 21:37:10 -0000 Received: from tensilica.com (maui.hq.tensilica.com [192.168.10.9]) by mail-in.hq.tensilica.com (8.11.6/8.9.3) with ESMTP id h41Lb3604253; Thu, 1 May 2003 14:37:03 -0700 Message-ID: <3EB1937F.6090304@tensilica.com> Date: Thu, 01 May 2003 21:37:00 -0000 From: David Heine Organization: Tensilica, Inc User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.1) Gecko/20020827 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Nick Clifton , binutils@sources.redhat.com Subject: Re: Bad behavior with explicit phdrs and loadable orphans References: <3EA5B717.8010904@tensilica.com> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg00015.txt.bz2 Nick Clifton wrote: > Hi David, > > >>When explicit PHDRs and memory regions are used with orphan input >>sections, the default placement of these sections can generate either >>very large files or a SEEK overflow. > > > Note - your problem could also be overcome by fixing the linker script > to provide a better definition for the memory regions. For example in > your script if you change: > > >>MEMORY >>{ >> normal_seg : ORIGIN = 0xd0000000, LENGTH = 0x10000 >>} > > > To: > > MEMORY > { > normal_seg (wax) : ORIGIN = 0xd0000000, LENGTH = 0x10000 > } > > The link will work. But anyway, this is only a workaround, not a full > solution. > > An alternative is the patch below will also work. It "fixes" > lang_memory_default() so that if a memory region does not have any > flags set, then it will accept any input section. This seems to be a > better interpretation of how a memory region without attributes is > supposed to behave. > > > >>This behavior seems a little extreme for misnaming a loadable >>section, but I'm not sure what a good solution would be. The ld >>orphan placement algorithm seems to be looking for a good place to >>put the section in the emulation statements. Perhaps it just needs >>to look for a good memory region while placing an orphan as well. >>Alternatively, when explicit PHDRS are used, the linker could do a >>better job of placing the default memory section so that it was >>reasonably contiguous with an existing PHDR. Or perhaps orphan >>loadable sections should generate an error when using explicit PHDRs >>before the attempt is made to build a multi-gigabyte file. > > > I think that the linker ought to try to be a little bit better about > choosing memory regions for orphan sections. Ideally it ought to > attempt to discover if the section it has chosen to inherit the orphan > has a memory region associated with it, and if so, use that region. > (Assuming that there is room of course). > > Let me know what you think > > Cheers > Nick > Nick, Thanks for taking a look. My initial thoughts on this were to find a better memory region to put the orphan section like you've implemented. However, the problem that caused the initial bad behavior was that an assembly file had mis-spelled a section name. While the proposed patch keeps the system from generating a large file or causing the SEEK overflow in this case, the problem would recur with any orphan that can not be placed by this default placement algorithm for some linker script. Because the patch manages to place the orphan section, it also removes the warning that indicated the actual problem: warning: no memory region specified for section For our target when using explicit memory regions, it is usually an error to have orphan sections that are loadable and allocatable for non-relocatable links. I'm not sure if this is generally true for other targets, but the existence of the original warning indicates that it might be. It might be better to keep the old placement algorithm and convert the warning: "no memory region specified for section" into a failure that will avoid the massive file generation. If you think the new placement algorithm makes more sense, it would probably be less intrusive to other targets if it were modified to first look for regions that match one of the positive attributes, then look for ones with no attributes so that the behavior only changes for sections that were previously unplaced. Also, adding an interface in ldlang.c that determines whether explicit memory regions are used (like the test guarding the "no memory region specified for section" warning) would allow target-specific code to generate a warning about orphan loadable,allocatable sections when using explicit memory regions. -David