[U-Boot] OMAP3: EVM: Linker errors across tool chain versions
What's the status of the linker errors across tool chain versions seen by building the 'omap3_evm' board?
This was already discussed in the threads [1] and [2], but it seems to me that there was no acceptable fix, yet?
E.g. with CodeSourcery's tool chain 2009q1-203 I get
arm-none-linux-gnueabi-ld: section .bss [8003f5e0 -> 8007e33f] overlaps section .rel.dyn [8003f5e0 -> 80044e6f] arm-none-linux-gnueabi-ld: section .dynsym [80044e70 -> 80044f0f] overlaps section .bss [8003f5e0 -> 8007e33f] arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5e0 overlaps previous sections
What we learned from [2] is that using [3] fixes the build (at least for me with the tool chain mentioned above). I.e. converting omap3_evm_version from u8 to int
-static u8 omap3_evm_version; +static int omap3_evm_version;
makes the issue disappear.
But if I understood the discussion correctly, this is no acceptable fix and can be used only as debug help (?).
Any further hints?
Thanks
Dirk
[1] ARMv7: Fix linker errors across toolchain versions http://lists.denx.de/pipermail/u-boot/2010-December/082874.html
[2] omap3evm: Clean-up EVM detection code http://lists.denx.de/pipermail/u-boot/2010-December/082950.html
[3] board/ti/evm/evm.c | 4 ++-- board/ti/evm/evm.h | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-)
Index: u-boot.git/board/ti/evm/evm.c =================================================================== --- u-boot.git.orig/board/ti/evm/evm.c +++ u-boot.git/board/ti/evm/evm.c @@ -37,9 +37,9 @@ #include <asm/mach-types.h> #include "evm.h"
-static u8 omap3_evm_version; +static int omap3_evm_version;
-u8 get_omap3_evm_rev(void) +int get_omap3_evm_rev(void) { return omap3_evm_version; } Index: u-boot.git/board/ti/evm/evm.h =================================================================== --- u-boot.git.orig/board/ti/evm/evm.h +++ u-boot.git/board/ti/evm/evm.h @@ -45,7 +45,7 @@ enum { OMAP3EVM_BOARD_GEN_2, /* EVM Rev >= Rev E */ };
-u8 get_omap3_evm_rev(void); +int get_omap3_evm_rev(void);
#if defined(CONFIG_CMD_NET) static void setup_net_chip(void);
Hi Dirk,
Le 12/12/2010 09:25, Dirk Behme a écrit :
What's the status of the linker errors across tool chain versions seen by building the 'omap3_evm' board?
This was already discussed in the threads [1] and [2], but it seems to me that there was no acceptable fix, yet?
E.g. with CodeSourcery's tool chain 2009q1-203 I get
arm-none-linux-gnueabi-ld: section .bss [8003f5e0 -> 8007e33f] overlaps section .rel.dyn [8003f5e0 -> 80044e6f] arm-none-linux-gnueabi-ld: section .dynsym [80044e70 -> 80044f0f] overlaps section .bss [8003f5e0 -> 8007e33f] arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5e0 overlaps previous sections
What we learned from [2] is that using [3] fixes the build (at least for me with the tool chain mentioned above). I.e. converting omap3_evm_version from u8 to int
-static u8 omap3_evm_version; +static int omap3_evm_version;
makes the issue disappear.
But if I understood the discussion correctly, this is no acceptable fix and can be used only as debug help (?).
Any further hints?
Three comments at least:
1. I personally would agree with the change to int, but since Wolfgang considers it a workaround to the linker issue, I won't accept it either.
2. IIRC, the linker emits a warning, not an error. We can live some time with a warning if it is documented and it is being worked on.
3. I did offer to try and find a minimal test case (one .c file, one .lds file, one simple command line) to cause the warning and submit it to the binutils list, but haven't had time so far.
Thanks
Dirk
Amicalement,
On 12.12.2010 11:08, Albert ARIBAUD wrote:
Hi Dirk,
Le 12/12/2010 09:25, Dirk Behme a écrit :
What's the status of the linker errors across tool chain versions seen by building the 'omap3_evm' board?
This was already discussed in the threads [1] and [2], but it seems to me that there was no acceptable fix, yet?
E.g. with CodeSourcery's tool chain 2009q1-203 I get
arm-none-linux-gnueabi-ld: section .bss [8003f5e0 -> 8007e33f] overlaps section .rel.dyn [8003f5e0 -> 80044e6f] arm-none-linux-gnueabi-ld: section .dynsym [80044e70 -> 80044f0f] overlaps section .bss [8003f5e0 -> 8007e33f] arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5e0 overlaps previous sections
What we learned from [2] is that using [3] fixes the build (at least for me with the tool chain mentioned above). I.e. converting omap3_evm_version from u8 to int
-static u8 omap3_evm_version; +static int omap3_evm_version;
makes the issue disappear.
But if I understood the discussion correctly, this is no acceptable fix and can be used only as debug help (?).
Any further hints?
Three comments at least:
- I personally would agree with the change to int, but since Wolfgang
considers it a workaround to the linker issue, I won't accept it either.
- IIRC, the linker emits a warning, not an error. We can live some
time with a warning if it is documented and it is being worked on.
With 2009q1-203 it's an error and 'omap3_evm' isn't built:
arm-none-linux-gnueabi-ld: section .bss [8003f5e0 -> 8007e33f] overlaps section .rel.dyn [8003f5e0 -> 80044e6f]
arm-none-linux-gnueabi-ld: section .dynsym [80044e70 -> 80044f0f] overlaps section .bss [8003f5e0 -> 8007e33f]
arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5e0 overlaps previous sections make: *** [u-boot] Error 1
size: './u-boot': No such file
Thanks
Dirk
- I did offer to try and find a minimal test case (one .c file, one
.lds file, one simple command line) to cause the warning and submit it to the binutils list, but haven't had time so far.
Thanks
Dirk
Amicalement,
Le 12/12/2010 11:32, Dirk Behme a écrit :
- IIRC, the linker emits a warning, not an error. We can live some
time with a warning if it is documented and it is being worked on.
With 2009q1-203 it's an error and 'omap3_evm' isn't built:
arm-none-linux-gnueabi-ld: section .bss [8003f5e0 -> 8007e33f] overlaps section .rel.dyn [8003f5e0 -> 80044e6f]
arm-none-linux-gnueabi-ld: section .dynsym [80044e70 -> 80044f0f] overlaps section .bss [8003f5e0 -> 8007e33f]
arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5e0 overlaps previous sections make: *** [u-boot] Error 1
size: './u-boot': No such file
Actually that's not exact. If you do a ./MAKEALL omap3_evm, yes, the build will fail. But (with 2010q1 at least, but I d'wager this works with 2009q3 as well) a 'make distclean; make omap3_evm_config; make' builds despite the linker message.
Can you try this as a diagnostic measure?
Also, you may want to try adding --no-check-sections to the linker flags -- again as a diagnostic measure only, not as a fix -- because a quick test shows me that the .bin is really different then.
Amicalement,
On 12.12.2010 12:40, Albert ARIBAUD wrote:
Le 12/12/2010 11:32, Dirk Behme a écrit :
- IIRC, the linker emits a warning, not an error. We can live some
time with a warning if it is documented and it is being worked on.
With 2009q1-203 it's an error and 'omap3_evm' isn't built:
arm-none-linux-gnueabi-ld: section .bss [8003f5e0 -> 8007e33f] overlaps section .rel.dyn [8003f5e0 -> 80044e6f]
arm-none-linux-gnueabi-ld: section .dynsym [80044e70 -> 80044f0f] overlaps section .bss [8003f5e0 -> 8007e33f]
arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5e0 overlaps previous sections make: *** [u-boot] Error 1
size: './u-boot': No such file
Actually that's not exact. If you do a ./MAKEALL omap3_evm, yes, the build will fail. But (with 2010q1 at least, but I d'wager this works with 2009q3 as well) a 'make distclean; make omap3_evm_config; make' builds despite the linker message.
Can you try this as a diagnostic measure?
Also, you may want to try adding --no-check-sections to the linker flags -- again as a diagnostic measure only, not as a fix -- because a quick test shows me that the .bin is really different then.
I did a readelf analysis for 3 test cases (with 2009q1-203):
1) As reference, I built 'omap3_beagle' assuming that this is somehow the ELF file layout we want. Result [1].
2) Build 'omap3_evm' with the 'convert omap3_evm_version to int patch' from
http://lists.denx.de/pipermail/u-boot/2010-December/083524.html
applied. Result [2].
3) Build 'omap3_evm' without any code patches, but with the additional linker option --no-check-sections. Result [3].
Looking at (1) and (2) both built fine and the resulting ELF files have 2 program headers.
In contrast to this, the resulting ELF file for (3) looks totally different with 3 program headers, an additional one just for .dynsym.
So (3) looks really like a tool chain issue to me. By whatever reason using 'omap3_evm_version' as a u8 somehow breaks the linking with some tool chains. Or at least outputs a warning and creates an ELF file with totally different section headers.
Comparing the resulting ELF file from 'omap3_beagle' (1) to the version with the int (2) it seems to me that this is what we want.
So I'd like to re-send the int conversion patch from
http://lists.denx.de/pipermail/u-boot/2010-December/083524.html
in a proper format again as a workaround for this issue.
Ok?
Thanks
Dirk
[1] omap3_beagle: ================
... Number of program headers: 2
Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al ... [ 7] .rel.dyn REL 800420c4 0420c4 005af0 08 A 8 0 4 [ 8] .dynsym DYNSYM 80047bb4 047bb4 0000a0 10 A 0 3 4 [ 9] .bss NOBITS 800420c4 000000 031bb4 00 WA 0 0 8 ...
Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x008000 0x80008000 0x80008000 0x3fc54 0x3fc54 RWE 0x8000 GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
Section to Segment mapping: Segment Sections... 00 .text .rodata .hash .data .got.plt .u_boot_cmd .rel.dyn .dynsym 01
...
[2] omap3_evm (with 'convert omap3_evm_version to int patch'): ============
... Number of program headers: 2 ...
Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al ... [ 7] .rel.dyn REL 8003f5e8 03f5e8 005890 08 A 8 0 4 [ 8] .dynsym DYNSYM 80044e78 044e78 0000a0 10 A 0 3 4 [ 9] .bss NOBITS 8003f5e8 000000 03ed60 00 WA 0 0 8 ...
Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x008000 0x80008000 0x80008000 0x3cf18 0x3cf18 RWE 0x8000 GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
Section to Segment mapping: Segment Sections... 00 .text .rodata .hash .data .got.plt .u_boot_cmd .rel.dyn .dynsym 01
...
[3] omap3_evm (code unpatched, with --no-check-sections): ============
... Number of program headers: 3 ...
Section Headers: [Nr] Name Type Addr Off Size ES Flg Lk Inf Al ... [ 7] .rel.dyn REL 8003f5e0 03f5e0 005890 08 A 8 0 4 [ 8] .dynsym DYNSYM 80044e70 044e70 0000a0 10 A 0 3 4 [ 9] .bss NOBITS 8003f5e0 044e70 03ed60 00 WA 0 0 8 ...
Program Headers: Type Offset VirtAddr PhysAddr FileSiz MemSiz Flg Align LOAD 0x008000 0x80008000 0x80008000 0x3ce70 0x7bbd0 RWE 0x8000 LOAD 0x044e70 0x80044e70 0x80044e70 0x000a0 0x000a0 R 0x8000 GNU_STACK 0x000000 0x00000000 0x00000000 0x00000 0x00000 RWE 0x4
Section to Segment mapping: Segment Sections... 00 .text .rodata .hash .data .got.plt .u_boot_cmd .rel.dyn .bss 01 .dynsym 02
...
Le 14/12/2010 16:42, Dirk Behme a écrit :
(agree about the analysis)
So I'd like to re-send the int conversion patch from
http://lists.denx.de/pipermail/u-boot/2010-December/083524.html
in a proper format again as a workaround for this issue.
Ok?
I think Wolfgang does not want this fix if it is a workaround to a bug, although it is not clear to me if this includes toolchain bugs. In any case, the decision will be Wolfgang's, so it's best if he's Cc:ed just in case.
Thanks
Dirk
Amicalement,
Dear Albert ARIBAUD,
In message 4D0794CF.5090608@free.fr you wrote:
I think Wolfgang does not want this fix if it is a workaround to a bug, although it is not clear to me if this includes toolchain bugs. In any case, the decision will be Wolfgang's, so it's best if he's Cc:ed just in case.
I'm perfectly willing to accept workarounds for bugs. But before fixing or working around some suspected bug we should first _understand_ what is happening. And here this is not the case.
We do not understand yet what is going wrong, or why. We don;t even know if it's really depending on some too chain configuration or version.
The risk is that we apply this patch now, and the problem which has not been actually fixed will bit us somewhere else again later.
Please let's try understanding what goes wrong, and who is to blame for it.
Best regards,
Wolfgang Denk
Am 14.12.2010 17:01, schrieb Albert ARIBAUD:
Le 14/12/2010 16:42, Dirk Behme a écrit :
(agree about the analysis)
So I'd like to re-send the int conversion patch from
http://lists.denx.de/pipermail/u-boot/2010-December/083524.html
in a proper format again as a workaround for this issue.
Ok?
I think Wolfgang does not want this fix if it is a workaround to a bug, although it is not clear to me if this includes toolchain bugs. In any case, the decision will be Wolfgang's, so it's best if he's Cc:ed just in case.
To put some salt into the wounds ;) , Using gcc 4.5.1 board_init_f isn't reached here. When I'm using gcc 4.3.5 it is reached. In both cases I've used the same version of binutils, 2.20.1.
For a test without using jtag, I've modified board_init_f to be
----------- board_init_f() { turn_on_leds while(1) ; ... }
I'm working with the master (f8689b9eb3a7f6925cd50404a12479889188c510) on a beagleboard, using -------- make mrproper make omap3_beagle_config make --------
to build u-boot.bin. So now it seems we have to look at some difference regarding versions of gcc and not binutils.
I will have a look if I will found out more, currently I'm not sure what else is called from start.S before board_init_f().
Regards,
Alexander
Am 16.12.2010 14:47, schrieb Alexander Holler:
To put some salt into the wounds ;) , Using gcc 4.5.1 board_init_f isn't reached here. When I'm using gcc 4.3.5 it is reached. In both cases I've used the same version of binutils, 2.20.1.
For a test without using jtag, I've modified board_init_f to be
board_init_f() { turn_on_leds while(1) ; ... }
I'm working with the master (f8689b9eb3a7f6925cd50404a12479889188c510) on a beagleboard, using
make mrproper make omap3_beagle_config make
To be precise, turn_on_leds is:
------- // GPIO5 #define GPIO5_OE (*((volatile unsigned long *)0x49056034)) // Output Data Enable Register (Table 24-27) #define GPIO5_DATAOUT (*((volatile unsigned long *)0x4905603C)) // Data Out register (Table 24-31) #define LED1 0x00200000 // Bit 21 #define LED0 0x00400000 // Bit 22 // PRCM #define CM_FCLKEN_PER (*((volatile unsigned long *)0x48005000)) // Controls the modules functional clock activity. (Table 4-237) #define CM_ICLKEN_PER (*((volatile unsigned long *)0x48005010)) // Controls the modules interface clock activity (Table 4-239) // SCM #define CONTROL_PADCONF_UART1_TX (*((volatile unsigned long *)0x4800217C)) // Pad configuration for GPIO_149 [31:16] (Tables 7-4 & 7-74) #define CONTROL_PADCONF_UART1_CTS (*((volatile unsigned long *)0x48002180)) // Pad configuration for GPIO_150 [15:0] (Tables 7-4 & 7-74) // Set the pinmux to select the GPIO signal CONTROL_PADCONF_UART1_TX &= 0x0000FFFF; // [31:16]=GPIO_149 - Clear register bits [31:16] CONTROL_PADCONF_UART1_TX |= 0x00040000; // [31:16]=GPIO_149 - select mux mode 4 for gpio CONTROL_PADCONF_UART1_TX &= 0xFFFF0000; // [15:0] =GPIO_150 - Clear register [15:0] CONTROL_PADCONF_UART1_TX |= 0x00000004; // [15:0] =GPIO_150 - select mux mode 4 for gpio // Switch on the Interface and functional clocks to the GPIO5 module CM_FCLKEN_PER |= 0x20; // Enable GPIO5 F clock CM_FCLKEN_PER |= 0x20; // Enable GPIO5 I clock // Configure the GPIO signals GPIO5_OE &= ~(LED1+LED0); // Set GPIO_149 & GPIO_150 (GPIO 4 bit 2) to output GPIO5_DATAOUT |= LED0; // Set GPIO_150 high GPIO5_DATAOUT |= LED1; // Set GPIO_149 high //GPIO5_DATAOUT &= ~LED1; // Set GPIO_149 low -------
(code stolen from somewhere on the web, just to show bss isn't used here)
Regards,
Alexander
On 16.12.2010 14:47, Alexander Holler wrote:
Am 14.12.2010 17:01, schrieb Albert ARIBAUD:
Le 14/12/2010 16:42, Dirk Behme a écrit :
(agree about the analysis)
So I'd like to re-send the int conversion patch from
http://lists.denx.de/pipermail/u-boot/2010-December/083524.html
in a proper format again as a workaround for this issue.
Ok?
I think Wolfgang does not want this fix if it is a workaround to a bug, although it is not clear to me if this includes toolchain bugs. In any case, the decision will be Wolfgang's, so it's best if he's Cc:ed just in case.
To put some salt into the wounds ;) , Using gcc 4.5.1 board_init_f isn't reached here. When I'm using gcc 4.3.5 it is reached. In both cases I've used the same version of binutils, 2.20.1.
For a test without using jtag, I've modified board_init_f to be
board_init_f() { turn_on_leds while(1) ; ... }
I'm working with the master (f8689b9eb3a7f6925cd50404a12479889188c510) on a beagleboard
^^^^^^^^^^^^^^
?
This thread is about a (linking) issue building 'omap3_evm'.
The Beagle support in the master you mention above is said to be fine.
Dirk
Am 16.12.2010 16:20, schrieb Dirk Behme:
On 16.12.2010 14:47, Alexander Holler wrote:
I'm working with the master (f8689b9eb3a7f6925cd50404a12479889188c510) on a beagleboard
^^^^^^^^^^^^^^?
This thread is about a (linking) issue building 'omap3_evm'.
The Beagle support in the master you mention above is said to be fine.
Sorry for going into this thread, but I've heard such a "fine" something like a dozens time before. And the beagleboard and the EVM are using the same start.S, so I thought I throw something into this thread about problems across tool chain versions. Even when it isn't about linker errors.
I will be silent again.
Regards,
Alexander
Dear Dirk,
In message 4D079060.70104@googlemail.com you wrote:
I did a readelf analysis for 3 test cases (with 2009q1-203):
Which exact versions of GCC and binutils is this?
Do we see any differences in board/ti/evm/evm.o ?
Can just use a different linker?
Or use a different tool chain for the compilation part, and use the linker from 2009q1-203 ?
I would really like to nail this down to a specific tool / version.
Best regards,
Wolfgang Denk
On 14.12.2010 17:21, Wolfgang Denk wrote:
Dear Dirk,
In message4D079060.70104@googlemail.com you wrote:
I did a readelf analysis for 3 test cases (with 2009q1-203):
Which exact versions of GCC and binutils is this?
gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203). For binutils versions (linker) see below.
Do we see any differences in board/ti/evm/evm.o ?
I compiled 'omap3_evm' with only above tool chain. Then linked with four different linkers, see your next question. I.e. it's always the same board/ti/evm/evm.o linked with four different linkers.ll
Can just use a different linker?
Yes. Compile 'omap3_evm' with 2009q1-203 and link the objects with four different linkers:
GNU ld (Sourcery G++ Lite 2009q1-203) 2.19.51.20090205 arm-2009q1/bin/arm-none-linux-gnueabi-ld: section .bss [8003f5e0 -> 8007e337] overlaps section .rel.dyn [8003f5e0 -> 80044e57] arm-2009q1/bin/arm-none-linux-gnueabi-ld: section .dynsym [80044e58 -> 80044ef7] overlaps section.bss [8003f5e0 -> 8007e337] arm-2009q1/bin/arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5e0 overlaps previous sections ls: Access to u-boot not possible: File or directory not found
GNU ld (Sourcery G++ Lite 2009q3-67) 2.19.51.20090709 arm-2009q3/bin/arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5e0 overlaps previous sections -rwxr-xr-x 1 dirk users 911743 16. Dez 10:30 u-boot
GNU ld (Sourcery G++ Lite 2010q1-202) 2.19.51.20090709 arm-2010q1/bin/arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5e0 overlaps previous sections -rwxr-xr-x 1 dirk users 911743 16. Dez 10:30 u-boot
GNU ld (Sourcery G++ Lite 2010.09-50) 2.20.51.20100809 -rwxr-xr-x 1 dirk users 911743 16. Dez 10:30 u-boot
Or use a different tool chain for the compilation part, and use the linker from 2009q1-203 ?
Using then the most recent Codesourcery gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) for compilation and the same linkers as above for the linking stage results in
GNU ld (Sourcery G++ Lite 2009q1-203) 2.19.51.20090205 arm-2009q1/bin/arm-none-linux-gnueabi-ld: u-boot: Unknown mandatory EABI object attribute 44 arm-2009q1/bin/arm-none-linux-gnueabi-ld: failed to merge target specific data of file arch/arm/cpu/armv7/libarmv7.o
.... arm-2009q1/bin/arm-none-linux-gnueabi-ld: section .bss [8003e158 -> 8007ceaf] overlaps section .rel.dyn [8003e158 -> 80043897]
arm-2009q1/bin/arm-none-linux-gnueabi-ld: section .dynsym [80043898 -> 80043937] overlaps section .bss [8003e158 -> 8007ceaf]
arm-2009q1/bin/arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003e158 overlaps previous sections
ls: Access to u-boot not possible: File or directory not found
GNU ld (Sourcery G++ Lite 2009q3-67) 2.19.51.20090709 arm-2009q3/bin/arm-none-linux-gnueabi-ld: u-boot: Unknown mandatory EABI object attribute 44 arm-2009q3/bin/arm-none-linux-gnueabi-ld: failed to merge target specific data of file arch/arm/cpu/armv7/libarmv7.o
.... arm-2009q3/bin/arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003e158 overlaps previous sections ls: Access to u-boot not possible: File or directory not found
GNU ld (Sourcery G++ Lite 2010q1-202) 2.19.51.20090709 arm-2010q1/bin/arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003e158 overlaps previous sections -rwxr-xr-x 1 dirk users 981801 16. Dez 10:41 u-boot
GNU ld (Sourcery G++ Lite 2010.09-50) 2.20.51.20100809 -rwxr-xr-x 1 dirk users 981801 16. Dez 10:41 u-boot
I would really like to nail this down to a specific tool / version.
Does this help?
Thanks
Dirk
On 16.12.2010 11:10, Dirk Behme wrote:
On 14.12.2010 17:21, Wolfgang Denk wrote:
Dear Dirk,
In message4D079060.70104@googlemail.com you wrote:
I did a readelf analysis for 3 test cases (with 2009q1-203):
Which exact versions of GCC and binutils is this?
gcc version 4.3.3 (Sourcery G++ Lite 2009q1-203). For binutils versions (linker) see below.
Do we see any differences in board/ti/evm/evm.o ?
I compiled 'omap3_evm' with only above tool chain. Then linked with four different linkers, see your next question. I.e. it's always the same board/ti/evm/evm.o linked with four different linkers.ll
Can just use a different linker?
Yes. Compile 'omap3_evm' with 2009q1-203 and link the objects with four different linkers:
GNU ld (Sourcery G++ Lite 2009q1-203) 2.19.51.20090205 arm-2009q1/bin/arm-none-linux-gnueabi-ld: section .bss [8003f5e0 -> 8007e337] overlaps section .rel.dyn [8003f5e0 -> 80044e57] arm-2009q1/bin/arm-none-linux-gnueabi-ld: section .dynsym [80044e58 -> 80044ef7] overlaps section.bss [8003f5e0 -> 8007e337] arm-2009q1/bin/arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5e0 overlaps previous sections ls: Access to u-boot not possible: File or directory not found
GNU ld (Sourcery G++ Lite 2009q3-67) 2.19.51.20090709 arm-2009q3/bin/arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5e0 overlaps previous sections -rwxr-xr-x 1 dirk users 911743 16. Dez 10:30 u-boot
GNU ld (Sourcery G++ Lite 2010q1-202) 2.19.51.20090709 arm-2010q1/bin/arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003f5e0 overlaps previous sections -rwxr-xr-x 1 dirk users 911743 16. Dez 10:30 u-boot
GNU ld (Sourcery G++ Lite 2010.09-50) 2.20.51.20100809 -rwxr-xr-x 1 dirk users 911743 16. Dez 10:30 u-boot
Or use a different tool chain for the compilation part, and use the linker from 2009q1-203 ?
Using then the most recent Codesourcery gcc version 4.5.1 (Sourcery G++ Lite 2010.09-50) for compilation and the same linkers as above for the linking stage results in
GNU ld (Sourcery G++ Lite 2009q1-203) 2.19.51.20090205 arm-2009q1/bin/arm-none-linux-gnueabi-ld: u-boot: Unknown mandatory EABI object attribute 44 arm-2009q1/bin/arm-none-linux-gnueabi-ld: failed to merge target specific data of file arch/arm/cpu/armv7/libarmv7.o
.... arm-2009q1/bin/arm-none-linux-gnueabi-ld: section .bss [8003e158 -> 8007ceaf] overlaps section .rel.dyn [8003e158 -> 80043897]
arm-2009q1/bin/arm-none-linux-gnueabi-ld: section .dynsym [80043898 -> 80043937] overlaps section .bss [8003e158 -> 8007ceaf]
arm-2009q1/bin/arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003e158 overlaps previous sections
ls: Access to u-boot not possible: File or directory not found
GNU ld (Sourcery G++ Lite 2009q3-67) 2.19.51.20090709 arm-2009q3/bin/arm-none-linux-gnueabi-ld: u-boot: Unknown mandatory EABI object attribute 44 arm-2009q3/bin/arm-none-linux-gnueabi-ld: failed to merge target specific data of file arch/arm/cpu/armv7/libarmv7.o
.... arm-2009q3/bin/arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003e158 overlaps previous sections ls: Access to u-boot not possible: File or directory not found
GNU ld (Sourcery G++ Lite 2010q1-202) 2.19.51.20090709 arm-2010q1/bin/arm-none-linux-gnueabi-ld: u-boot: section .bss vma 0x8003e158 overlaps previous sections -rwxr-xr-x 1 dirk users 981801 16. Dez 10:41 u-boot
GNU ld (Sourcery G++ Lite 2010.09-50) 2.20.51.20100809 -rwxr-xr-x 1 dirk users 981801 16. Dez 10:41 u-boot
I would really like to nail this down to a specific tool / version.
Does this help?
Any comments on this? If we would come to a conclusion, soon, I'd like to get a fix integrated for v2010.12.
Thanks
Dirk
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Dirk Behme Sent: Friday, December 17, 2010 4:10 PM To: Wolfgang Denk Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] OMAP3: EVM: Linker errors across tool chain versions
[snip]...[snip]
GNU ld (Sourcery G++ Lite 2010.09-50) 2.20.51.20100809 -rwxr-xr-x 1 dirk users 981801 16. Dez 10:41 u-boot
I would really like to nail this down to a specific tool / version.
Does this help?
Any comments on this? If we would come to a conclusion, soon, I'd like to get a fix integrated for v2010.12.
[sp] I had to be away from work for most of this month to attend a personal emergency.
Haven't yet followed on this/ related threads to check if the issue has really been taken care of.
Will spend next few days to get current on it...
~sanjeev
Thanks
Dirk _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
participants (5)
-
Albert ARIBAUD -
Alexander Holler -
Dirk Behme -
Premi, Sanjeev -
Wolfgang Denk