LTO vs. default section alignment vs. relocatable links.

LTO vs. default section alignment vs. relocatable links.

[Dave Korn]

    Hi all,

  LTO IR sections need to have 1-byte alignment, and that is how we get them
from GAS.  So far so good, but when we do a -r link of two object files, the
placement of the LTO sections is handle by orphan handling, since there aren't
any LTO section output statements in any of the default linker scripts (yet).

  In practice, this leads (at least on i686-pc-cygwin) to the sections being
placed after .rodata, and they get the default section alignment.  That causes
their sizes to be rounded up to 4 with padding, which fatally confuses the
zlib decompressor in lto1 when we come to stream them back in later.

  Rather than modifying all the default linker scripts, can we handle this by
creating a synthetic output statement of some kind at LD start-up?  Or should
this be considered a weakness of orphan placement; should it notice the
alignment of the input section and create a similarly aligned orphan output
section?

    cheers,
      DaveK

Re: LTO vs. default section alignment vs. relocatable links.

[H.J. Lu]

On Tue, Feb 1, 2011 at 1:44 PM, Dave Korn <dave.korn.cygwin@gmail.com> wrote:
>
>    Hi all,
>
>  LTO IR sections need to have 1-byte alignment, and that is how we get them
> from GAS.  So far so good, but when we do a -r link of two object files, the
> placement of the LTO sections is handle by orphan handling, since there aren't
> any LTO section output statements in any of the default linker scripts (yet).
>
>  In practice, this leads (at least on i686-pc-cygwin) to the sections being
> placed after .rodata, and they get the default section alignment.  That causes
> their sizes to be rounded up to 4 with padding, which fatally confuses the
> zlib decompressor in lto1 when we come to stream them back in later.
>
>  Rather than modifying all the default linker scripts, can we handle this by
> creating a synthetic output statement of some kind at LD start-up?  Or should
> this be considered a weakness of orphan placement; should it notice the
> alignment of the input section and create a similarly aligned orphan output
> section?

It isn't a problem on Linux. Is this a cygwin specific problem?


-- 
H.J.

Re: LTO vs. default section alignment vs. relocatable links.

[Alan Modra]

On Tue, Feb 01, 2011 at 09:44:51PM +0000, Dave Korn wrote:
> 
>     Hi all,
> 
>   LTO IR sections need to have 1-byte alignment, and that is how we get them
> from GAS.  So far so good, but when we do a -r link of two object files, the
> placement of the LTO sections is handle by orphan handling, since there aren't
> any LTO section output statements in any of the default linker scripts (yet).
> 
>   In practice, this leads (at least on i686-pc-cygwin) to the sections being
> placed after .rodata, and they get the default section alignment.  That causes
> their sizes to be rounded up to 4 with padding, which fatally confuses the
> zlib decompressor in lto1 when we come to stream them back in later.

This is a PE specific problem, isnt it?

      /* All sections in an executable must be aligned to a page boundary.  */
      address = exp_unop (ALIGN_K, exp_nameop (NAME, "__section_alignment__"));
      os = lang_insert_orphan (s, secname, constraint, after, place, address,
			       &add_child);

Fixable right there..

-- 
Alan Modra
Australia Development Lab, IBM

Re: LTO vs. default section alignment vs. relocatable links.

[Dave Korn]

On 01/02/2011 21:55, Alan Modra wrote:
> On Tue, Feb 01, 2011 at 09:44:51PM +0000, Dave Korn wrote:
>>     Hi all,
>>
>>   LTO IR sections need to have 1-byte alignment, and that is how we get them
>> from GAS.  So far so good, but when we do a -r link of two object files, the
>> placement of the LTO sections is handle by orphan handling, since there aren't
>> any LTO section output statements in any of the default linker scripts (yet).
>>
>>   In practice, this leads (at least on i686-pc-cygwin) to the sections being
>> placed after .rodata, and they get the default section alignment.  That causes
>> their sizes to be rounded up to 4 with padding, which fatally confuses the
>> zlib decompressor in lto1 when we come to stream them back in later.
> 
> This is a PE specific problem, isnt it?
> 
>       /* All sections in an executable must be aligned to a page boundary.  */
>       address = exp_unop (ALIGN_K, exp_nameop (NAME, "__section_alignment__"));
>       os = lang_insert_orphan (s, secname, constraint, after, place, address,
> 			       &add_child);
> 
> Fixable right there..

  That's where I was looking, but I didn't know if ELF wouldn't also do the
same thing.  Since HJ says it doesn't, that's definitely the right place to
fix it.

    cheers,
      DaveK