[U-Boot] OMAP3: EVM: Linker errors across tool chain versions

[U-Boot] OMAP3: EVM: Linker errors across tool chain versions

[Dirk Behme]

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);

[U-Boot] OMAP3: EVM: Linker errors across tool chain versions

[Albert ARIBAUD]

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,
-- 
Albert.

[U-Boot] OMAP3: EVM: Linker errors across tool chain versions

[Dirk Behme]

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:
>
> 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.

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

> 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,

[U-Boot] OMAP3: EVM: Linker errors across tool chain versions

[Albert ARIBAUD]

Le 12/12/2010 11:32, Dirk Behme a ?crit :

 >> 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.
 >
 > 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,
-- 
Albert.

[U-Boot] OMAP3: EVM: Linker errors across tool chain versions

[Dirk Behme]

On 12.12.2010 12:40, Albert ARIBAUD wrote:
> Le 12/12/2010 11:32, Dirk Behme a ?crit :
>
>  >> 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.
>  >
>  > 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

...

[U-Boot] OMAP3: EVM: Linker errors across tool chain versions

[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.

> Thanks
>
> Dirk

Amicalement,
-- 
Albert.

[U-Boot] OMAP3: EVM: Linker errors across tool chain versions

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Es ist offensichtlich, dass das menschliche Gehirn wie  ein  Computer
funktioniert.  Da  es  keine  dummen Computer gibt, gibt es also auch
keine dummen Menschen. Nur ein paar Leute, die unter DOS laufen.
                                                       -- <unbekannt>

[U-Boot] OMAP3: EVM: Linker errors across tool chain versions

[Alexander Holler]

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

[U-Boot] OMAP3: EVM: Linker errors across tool chain versions

[Alexander Holler]

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

[U-Boot] OMAP3: EVM: Linker errors across tool chain versions

[Dirk Behme]

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

[U-Boot] OMAP3: EVM: Linker errors across tool chain versions

[Alexander Holler]

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

[U-Boot] OMAP3: EVM: Linker errors across tool chain versions

[Wolfgang Denk]

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

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
Another megabytes the dust.

[U-Boot] OMAP3: EVM: Linker errors across tool chain versions

[Dirk Behme]

On 14.12.2010 17:21, Wolfgang Denk wrote:
> 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?

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

[U-Boot] OMAP3: EVM: Linker errors across tool chain versions

[Dirk Behme]

On 16.12.2010 11:10, Dirk Behme wrote:
> On 14.12.2010 17:21, Wolfgang Denk wrote:
>> 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?
>
> 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

[U-Boot] OMAP3: EVM: Linker errors across tool chain versions

[Premi, Sanjeev]

> -----Original Message-----
> From: u-boot-bounces at lists.denx.de 
> [mailto:u-boot-bounces at lists.denx.de] On Behalf Of Dirk Behme
> Sent: Friday, December 17, 2010 4:10 PM
> To: Wolfgang Denk
> Cc: u-boot at 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 at lists.denx.de
> http://lists.denx.de/mailman/listinfo/u-boot
>