This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#12397 - .data section alignment ignored on some targets
Attached to Project:
Rockbox
Opened by Boris Gjenero (dreamlayers) - Sunday, 20 November 2011, 21:55 GMT+2
Last edited by Boris Gjenero (dreamlayers) - Wednesday, 23 November 2011, 22:37 GMT+2
Opened by Boris Gjenero (dreamlayers) - Sunday, 20 November 2011, 21:55 GMT+2
Last edited by Boris Gjenero (dreamlayers) - Wednesday, 23 November 2011, 22:37 GMT+2
|
DetailsThe 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: http://www.rockbox.org/tracker/task/12391?getfile=24344 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, 22:37 GMT+2
Reason for closing: Fixed
Additional comments about closing: Fixed in r31041
Wednesday, 23 November 2011, 22:37 GMT+2
Reason for closing: Fixed
Additional comments about closing: Fixed in r31041
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 app.lds 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.