FS#12397 - .data section alignment ignored on some targets

Attached to Project: Rockbox
Opened by Boris Gjenero (dreamlayers) - Sunday, 20 November 2011, 20:55 GMT
Last edited by Boris Gjenero (dreamlayers) - Wednesday, 23 November 2011, 21:37 GMT
Task Type Bugs
Category Build environment
Status Closed
Assigned To No-one
Operating System All players
Severity Low
Priority Normal
Reported Version Daily build (which?)
Due in Version Undecided
Due Date Undecided
Percent Complete 100%
Votes 0
Private No


The iPod linker script contains a trick which causes .data to always be word aligned on disk. The section is not moved by startup code, so it remains word aligned in memory. If the section alignment was more strict, and as a result, more padding had to be added for alignment, .data would be at the wrong address in memory. This leads to a crash at startup.

The linker sets the section alignment to the strictest variable alignment in the section. Currently, nothing is increasing .data section alignment. The problem can only occur if a variable with more strict alignment (eg. CACHEALIGN_ATTR) is added to .data. Here's one example of how to trigger the problem:

This issue seems to be present in multiple targets. The solution should be simple: remove the linker script trick from all targets which don't have code to copy .data elsewhere. I'm attaching a patch which removes the trick for iPods. I'll track down the other targets later.

I don't think the ". = ALIGN(0x4);" lines have any purpose when . is not assigned to any value and the following section's alignment is respected, but .text has the line, so I'm not removing it from .rodata. I'm not very familiar with linker scripts.
This task depends upon

Closed by  Boris Gjenero (dreamlayers)
Wednesday, 23 November 2011, 21:37 GMT
Reason for closing:  Fixed
Additional comments about closing:  Fixed in r31041
Comment by Boris Gjenero (dreamlayers) - Tuesday, 22 November 2011, 19:05 GMT
I committed a fix in r31041. Sh and Coldfire targets still use the trick. That shouldn't cause problems because both have code in crt0.S which moves the data section. An optimization is possible in those cases, removing the trick from and excluding .data moving code when running from RAM. That would require separate compiles of crt0.S where Rockbox can run from either RAM or flash.