[Bug 1725] Output section alignment fix

[bugzilla-daemon at rtems.org]

https://www.rtems.org/bugzilla/show_bug.cgi?id=1725

--- Comment #6 from Sebastian Huber <sebastian.huber at embedded-brains.de> 2010-12-09 07:52:28 CST ---
(In reply to comment #5)
> (In reply to comment #4)
> > (In reply to comment #3)
> > > Talk to upstream binutils and have them integrate it into binutils-2.21-branch.
> > 
> > I already sent Alan Modra an email, but since this is probably not a regression
> > fix or documentation improvement I think that it is unlikely that this will be
> > back ported to the 2.21 branch.
> OK, then please explain why I should add it.

In RTEMS you have typically a lot of copy and paste linker command files.  For
the ARM port I started to change this.  Here you have a basic linker command
file

c/src/lib/libbsp/arm/shared/startup/linkcmds.base

that defines the standard System V ELF sections and maps them to memory
regions.  These memory regions are defined via region aliases in terms of
memory regions that correspond to areas of the target hardware.  This mapping
is done for each BSP variant, e.g.

c/src/lib/libbsp/arm/lpc24xx/startup/linkcmds.lpc24xx_ea

The alignment of an output section is derived from the maximum alignment of its
input sections and thus not known a priori.  The GNU ld without this patch has
now the following problem.

Lets look at this SECTIONS part of the linker command file:

    .jcr : {
        KEEP (*(.jcr))
    } > REGION AT > REGION
    .rodata : {
        *(.rodata .rodata.* .gnu.linkonce.r.*)
    } > REGION AT > REGION

The .rodata section has a section alignment of 8 (the alignment depends on the
application, it may be higher).  Now suppose that the .jcr end is not 8 bytes
aligned.  We may have this:

.jcr            0x00000000800198b0        0x4
 *(.jcr)
 .jcr           0x00000000800198b0        0x0 crtbegin.o
 .jcr           0x00000000800198b0        0x4 crtend.o

.rodata         0x00000000800198b8     0x2ba8 load address 0x00000000800198b4
 *(.rodata .rodata.* .gnu.linkonce.r.*)

This is pretty bad, since this introduces a 4 byte offset in the .rodata
section.  The patch eliminates this problem.  I know no workaround.

> binutils-2.21 was just released today and nobody so far (but you) has
> complained about this patch not having made it.

The target audience for this kind of fixes is very limited.

> 
> > > Also, next time on such occasions, add proper changelogs
> > 
> > Sorry, the change log is in the patch.
> 
> Apologies, I missed the changelog inside of the patch.

Ok, no problem.

> 
> >  How do you want this next time?
> All patches need changelog entries, esp. those to GCC, binutils and gdb,
> because these are the only possibility to "legitimate" them.
[...]

Should the change log entry be part of the patch or part of the PR message?

-- 
Configure bugmail: https://www.rtems.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.