[U-Boot] ld fails with .bss / .rel.dyn overlap for 2011.12
This email is to report a problem building u-boot 2011.12 with a gcc 4.3.2 toolchain. I've added support locally for a marvell 78xx0 based board. It's using arm926ejs and I have not modified the *.lds linker script.
Case 1: With gcc 4.3.2 provided by marvell, the build fails with this error:
arm-mv5vfp-linux-gnueabi-ld: section .bss [00000000fffbba08 -> 00000000fffc3137] overlaps section .rel.dyn [00000000fffbba08 -> 00000000fffbeea7] arm-mv5vfp-linux-gnueabi-ld: section .dynsym [00000000fffbeea8 -> 00000000fffbef57] overlaps section .bss [00000000fffbba08 -> 00000000fffc3137] arm-mv5vfp-linux-gnueabi-ld: u-boot: section .bss lma 0xfffbba08 overlaps previous sections make: *** [u-boot] Error 1
Through trial-and-error, I found that this error only occurs when .bss is unaligned. In my example .bss is only 2-byte aligned and u-boot.map indicates that the linker added 2-bytes of zero fill at the end of bss. If I add a global unsigned short so .bss is 4-byte aligned the error goes away and gcc produces a good binary.
Case 2: With gcc 4.6.3 built with crosstool-ng, the build has no problem.
I can provide u-boot.map files (~70k) for each case.
-joey
Dear Joey Oravec,
In message 4F834E09.3010600@drewtech.com you wrote:
This email is to report a problem building u-boot 2011.12 with a gcc 4.3.2 toolchain. I've added support locally for a marvell 78xx0 based board. It's using arm926ejs and I have not modified the *.lds linker script.
Case 1: With gcc 4.3.2 provided by marvell, the build fails with this error:
...
I can provide u-boot.map files (~70k) for each case.
Thanks, but what should we do about that? You are referring to code that is unknown to us, and to a tool chain we have no access to.
It would probably be best to report this to the Marvell compiler team.
Best regards,
Wolfgang Denk
On 4/9/2012 5:12 PM, Wolfgang Denk wrote:
Dear Joey Oravec,
In message4F834E09.3010600@drewtech.com you wrote:
This email is to report a problem building u-boot 2011.12 with a gcc 4.3.2 toolchain. I've added support locally for a marvell 78xx0 based board. It's using arm926ejs and I have not modified the *.lds linker script.
Case 1: With gcc 4.3.2 provided by marvell, the build fails with this error:
...
I can provide u-boot.map files (~70k) for each case.
Thanks, but what should we do about that? You are referring to code that is unknown to us, and to a tool chain we have no access to.
It would probably be best to report this to the Marvell compiler team.
Possibly nothing -- I'm reporting it because there have been other mailing list thread with the same error message, sometimes without a clear resolution:
http://lists.denx.de/pipermail/u-boot/2012-February/117009.html http://lists.denx.de/pipermail/u-boot/2010-November/082122.html
I don't know enough about the linker or *.map file to understand the root cause of the error message. I can only report my observations and suggest that if somebody else hits the same problem they should try using a newer toolchain. In my case it fixed the problem.
I don't need anybody to take any action on this, so feel free to disregard if this report is not interesting. I have no support through Marvell but I thought it was appropriate to share my results with this mailing list.
-joey
Dear Joey,
In message 4F835962.7010902@drewtech.com you wrote:
I don't need anybody to take any action on this, so feel free to disregard if this report is not interesting. I have no support through Marvell but I thought it was appropriate to share my results with this mailing list.
Please don't misunderstand me. This is certainly interesting information, and probably even important to some. Unfortunately we can do nothing to help it, as we don;t have access to the Marvell code nor tool chain.
I think you should still report it to Marvell, so they know as well.
Best regards,
Wolfgang Denk
On 10.04.2012 10:02, Wolfgang Denk wrote:
Dear Joey,
In message4F835962.7010902@drewtech.com you wrote:
I don't need anybody to take any action on this, so feel free to disregard if this report is not interesting. I have no support through Marvell but I thought it was appropriate to share my results with this mailing list.
Please don't misunderstand me. This is certainly interesting information, and probably even important to some. Unfortunately we can do nothing to help it, as we don;t have access to the Marvell code nor tool chain.
If I read the logs correctly, this was seen with other tool chains, e.g. Codesourcery ones, too.
But if I remember correctly, the conclusion was to use newer, not 'broken' tool chains. Whatever 'broken' does mean here ;)
Best regards
Dirk
participants (3)
-
Dirk Behme -
Joey Oravec -
Wolfgang Denk