-----Original Message----- From: Albert ARIBAUD [mailto:albert.aribaud@free.fr] Sent: Thursday, December 02, 2010 12:30 PM To: u-boot@lists.denx.de Cc: Premi, Sanjeev; Wolfgang Denk Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
Le 01/12/2010 22:39, Albert ARIBAUD a écrit :
This one is a conundrum.
Using 2010q1, building omap3_evm causes a linker warning "arm-none-linux-gnueabi-ld: u-boot: section .bss vma
0x8003e8f0 overlaps
previous sections" while building omap3_beagle does not
cause any linker
warning.
Both boards use the same armv7 u-boot.lds and have a .bss
which is way
bigger than the .rel.dyn plus .dynsym sections that it does overlay. IOW, they have a similar layout for .rel.dyn, .dynsym and
.bss, but one
gets the warning and one does not.
The one difference a readelf shows is that for beagle,
there is only one
segment:
00 .text .rodata .hash .data .got.plt .u_boot_cmd .rel.dyn .dynsym
While for evm there is
00 .text .rodata .hash .data .got.plt .u_boot_cmd .rel.dyn .bss 01 .dynsym
Note that .bss has appeared in segment 00 for evm, whereas
it was absent
for beagle, and that .dynsym was rejected to a second
segment -- why? I
don't know.
Note: I've tried with putting input sections .rel.dyn and
.dynsym into a
single output section .rel.dyn: this makes the second
segment disappear,
but for evm the warning remains and .bss remains in the segment.
I have a tiny clue.
Starting with the fact that the linker issue is only for one board, omap3_evm, I looked up the board-specific code. First thing that I noticed was
static u8 omap3_evm_version;
I changed this to
static u8 omap3_evm_version = 1;
so that the static was moved out of BSS and the linker warning disappeared (reminder: v2010.12-rc2, omap3_evm, arm-2010q1).
Now this is not the first static BSS variable we use in U-Boot, and the others did not cause linker warnings (not *all* the others, at least), so the real cause is yet unknown to me. But that's at least a lead we can follow.
If this BSS variable is used before relocation (I haven't checked this), then anyway it'll have to move; in that case I'll keep an eye on this linker warning and try to sort it out if I get time.
I did explain yesterday that variable is not used in relocation. If you notice the code snippet I sent yesterday, I had removed every assignment to the variable. And 2009q1 was still not happy!
Amicalement,
Albert.