Re: fix PR15222, excessive LMA alignment

[Sebastian Huber <sebastian dot huber at embedded-brains dot de>]

On 05/20/2013 03:47 PM, Alan Modra wrote:
> On Fri, May 17, 2013 at 03:26:08PM +0200, Sebastian Huber wrote:
> > This change can break linker command files that worked well before
> > this change.  Example:
>
> Yes, but they wouldn't have worked before
> http://sourceware.org/ml/binutils/2010-12/msg00004.html, would they?

Yes, they wouldn't have worked before this change.

> > How do we best address this problem?
> >
> > 1. Revert the change.
>
> And revert the above change too?  I ask that because the PR15222
> reporter's desired LMA behaviour is quite reasonable.  Yours is too,
> but if we revert just the PR15222 fix there isn't a way to get the old
> behaviour, whereas you can get the extra alignment you'd like with
> some script changes I think.  Note that the PR15222 fix didn't break
> your original reported problem when the LMA and VMA regions are the
> same, http://sourceware.org/ml/binutils/2010-11/msg00485.html.
>
> > 2. Select the behaviour depending on a command line or linker script option.
> > 3. Require to fix the existing linker command files.
>
> How many scripts are involved?  Sorry to be a pain, but (3) may be the
> best choice for the binutils project.

Yes, (3) is probably the best solution.

I just have to force the output section alignment to get a memcpy() without 
unaligned memory accesses:

http://sourceware.org/binutils/docs-2.23.1/ld/Forced-Output-Alignment.html#Forced-Output-Alignment

One drawback is that I have now fewer output sections in the ELF file.

Elf file type is EXEC (Executable file)
Entry point 0x4000
There are 4 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x0000c0 0x00004000 0x00004000 0x40f60 0x40f60 RWE 0x20
  LOAD           0x041020 0x01000000 0x00044f60 0x03078 0x1000000 RW  0x8
  LOAD           0x044098 0x02000000 0x00047fd8 0x00694 0x00694 RW  0x8
  LOAD           0x044734 0x02000694 0x02000694 0x00000 0xfff96c RW  0x20

 Section to Segment mapping:
  Segment Sections...
   00     .start .text .init .fini
   01     .rodata .sdata2 .eh_frame .ctors .dtors .jcr .got2 .rwbarrier
   02     .data .sdata
   03     .sbss .bss .rwextra .work

Elf file type is EXEC (Executable file)
Entry point 0x4000
There are 4 program headers, starting at offset 52

Program Headers:
  Type           Offset   VirtAddr   PhysAddr   FileSiz MemSiz  Flg Align
  LOAD           0x0000c0 0x00004000 0x00004000 0x40f60 0x40f60 RWE 0x20
  LOAD           0x041020 0x01000000 0x00044f60 0x03078 0x1000000 RW  0x10
  LOAD           0x044098 0x02000000 0x00047fd8 0x00694 0x00694 RW  0x8
  LOAD           0x044734 0x02000694 0x02000694 0x00000 0xfff96c RW  0x20

 Section to Segment mapping:
  Segment Sections...
   00     .start .text
   01     .rodata .sdata2 .rwbarrier
   02     .data .sdata
   03     .sbss .bss .rwextra .work

On some architectures like PowerPC I have to add additional memcpy()'s due to 
target specifics, e.g. "the target (XYZ) of a R_PPC_EMB_SDA21 relocation is in 
the wrong output section (.rodata)".

--
Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber@embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.