This is the mail archive of the binutils@sourceware.org mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: ld big trouble.


On Wed, Sep 02, 2009 at 04:51:16PM +0100, Dave Korn wrote:
> Alan Modra wrote:
> > On Wed, Sep 02, 2009 at 03:01:58PM +0100, Dave Korn wrote:
> >> GCC's partitioning options generate sections with names like ".text.unlikely",
> >> or ".text.cold" and ".text.hot".  Shouldn't these text sections be governed by
> >> the same text_read_only flag?  It breaks auto-import on PE platforms, because
> >> that requires that all text sections (well, all that have fixup imports
> >> anyway) be writable.
> > 
> > Input .text.* sections are usually merged in to the .text output
> > section on a final link.
> 
>   Right.  The PE scripts only include *(.text), and my initial plan was to
> just add *(.text.*).  But then it occurred to me: the reasoning behind this
> partitioning is to gain benefits from caching of frequently used stuff, and on
> that line of reasoning it might make sense to keep them as separate sections,
> so they can be allocated in separate memory pages that most OS's VMMs will
> swap out of the working set when they don't get frequently accessed.

You get cache locality by using a link script with
  .text { *(<hot_name_pattern>) *(<cold_name_pattern>) }

This causes the linker to place all hot sections together, followed by
cold sections.

Hmm, it looks like "gcc -freorder-blocks-and-partition" isn't properly
supported in ld at the moment.  I'll look at fixing that.

> >> "text_read_only" member appears to have been added without being mentioned in
> > 
> > It's main use was to make .text writable for omagic a.out binaries.
> 
>   IIRC a.out only supports a single section each for text, data and bss, so
> making the code alter the flags for other text sections wouldn't make any
> difference there.  But I notice that both generic.em and elf32.em at least
> respect it and use it to select alternate default linker scripts (haven't yet
> checked to see if there are *actually* any differences in the generated
> scripts), so I wouldn't want to do anything that might surprise anyone there.

We support omagic style ELF too.

> > I suspect that on !link_info.relocatable && !config.text_read_only you
> > could loop over all output sections removing SEC_READONLY, and do
> > nothing otherwise.  .text ought to be SEC_READONLY by default.
> 
>   All output sections?  Surely we wouldn't want to e.g. remove SEC_READONLY
> from .rdata and such?

Yes, I believe so.  ld -N (omagic) mashes all sections together (no
page alignment of data segment) which gives us just one read/write
segment for the whole program.

-- 
Alan Modra
Australia Development Lab, IBM


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]