Re: Bad behavior with explicit phdrs and loadable orphans

[David Heine <dlheine at tensilica dot com>]

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