[U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
This patch fixes the linker problems noticed while building the omap3_evm with Codesourcery toolchains 2009q1, 2009q3 and 2010q1.
The compilation was tested as success for both omap3_evm and omap3_beagle with toolchain versions 2009q1 and 2010q1.
[1] http://marc.info/?l=u-boot&m=129104332808386&w=2
Signed-off-by: Sanjeev Premi premi@ti.com --- The patch touches all ARMv7 architectures, will need to be reviewed thoroughly.
I am getting hang of relocation feature, but definitely hands-on. Impact would have to be reviewd as well. This is the reason for sending the patch early - before i start testing on the evm.
arch/arm/cpu/armv7/u-boot.lds | 26 +++++++++++++++----------- 1 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/arch/arm/cpu/armv7/u-boot.lds b/arch/arm/cpu/armv7/u-boot.lds index 5725c30..faf6ad8 100644 --- a/arch/arm/cpu/armv7/u-boot.lds +++ b/arch/arm/cpu/armv7/u-boot.lds @@ -55,22 +55,26 @@ SECTIONS
. = ALIGN(4);
- .rel.dyn : { - __rel_dyn_start = .; - *(.rel*) - __rel_dyn_end = .; - } - .dynsym : { __dynsym_start = .; *(.dynsym) }
- .bss __rel_dyn_start (OVERLAY) : { - __bss_start = .; - *(.bss) - . = ALIGN(4); - _end = .; + OVERLAY : NOCROSSREFS + { + .rel.dyn { + __rel_dyn_start = .; + *(.rel*) + __rel_dyn_end = .; + } + + .bss + { + __bss_start = .; + *(.bss) + . = ALIGN(4); + _end = .; + } }
/DISCARD/ : { *(.dynstr*) }
-----Original Message----- From: Premi, Sanjeev Sent: Wednesday, December 01, 2010 8:47 PM To: u-boot@lists.denx.de Cc: Premi, Sanjeev Subject: [PATCH] ARMv7: Fix linker errors across toolchain versions
This patch fixes the linker problems noticed while building the omap3_evm with Codesourcery toolchains 2009q1, 2009q3 and 2010q1.
The compilation was tested as success for both omap3_evm and omap3_beagle with toolchain versions 2009q1 and 2010q1.
[1] http://marc.info/?l=u-boot&m=129104332808386&w=2
Signed-off-by: Sanjeev Premi premi@ti.com
The patch touches all ARMv7 architectures, will need to be reviewed thoroughly.
I am getting hang of relocation feature, but definitely hands-on. Impact would have to be reviewd as well. This is the reason for sending the patch early - before i start testing on the evm.
arch/arm/cpu/armv7/u-boot.lds | 26 +++++++++++++++----------- 1 files changed, 15 insertions(+), 11 deletions(-)
[snip]...[snip]
The u-boot built after this change alone gets stuck somewhere after dram_init(). However, removing the "sort" from LIBS (as suggested by Wolfgang), the u-boot comes up fine on the omap3_evm.
[patch] diff --git a/Makefile b/Makefile index 87a383d..a530261 100644 --- a/Makefile +++ b/Makefile @@ -263,7 +263,7 @@ ifeq ($(SOC),s5pc2xx) LIBS += $(CPUDIR)/s5p-common/libs5p-common.o endif
-LIBS := $(addprefix $(obj),$(sort $(LIBS))) +LIBS := $(addprefix $(obj),$(LIBS)) .PHONY : $(LIBS) $(TIMESTAMP_FILE) $(VERSION_FILE)
LIBBOARD = board/$(BOARDDIR)/lib$(BOARD).o [/patch]
U-Boot 2010.12-rc2-00030-g4998cdc-dirty (Dec 01 2010 - 21:09:59)
OMAP3530-GP ES3.1, CPU-OPP2, L3-165MHz, Max CPU Clock 720 mHz OMAP3 EVM board + LPDDR/NAND I2C: ready DRAM: 256 MiB NAND: 256 MiB In: serial Out: serial Err: serial Read back SMSC id 0x92200000 Die ID #609200040000000004032d460c01201a Net: smc911x-0 Hit any key to stop autoboot: 0 OMAP3_EVM # OMAP3_EVM #
Here is my git-log (including the patch above): premi # g-log-10 4998cdc : ARMv7: Fix linker errors across toolchain versions 49733aa : Merge branch 'master' of /home/wd/git/u-boot/custodians f8264e0 : Merge branch 'master' of git://git.denx.de/u-boot-arm b194577 : hwconfig: Fix dummy initialization of {board, cpu}_hwconfig a55bb83 : powerpc/85xx: Introduce CONFIG_SYS_EXTRA_ENV_RELOC 52eb2c7 : Merge branch 'master' of git://git.denx.de/u-boot-samsung 83b622a : Merge branch 'master' of /home/wd/git/u-boot/custodians 3410a99 : Merge branch 'master' of git://git.denx.de/u-boot-sh a7bf3ec : Merge branch 'master' of /home/wd/git/u-boot/custodians e45c98a : mpc83xx: Make it boot again premi #
Dear "Premi, Sanjeev",
In message B85A65D85D7EB246BE421B3FB0FBB5930247AFDA69@dbde02.ent.ti.com you wrote:
The u-boot built after this change alone gets stuck somewhere after dram_init(). However, removing the "sort" from LIBS (as suggested by Wolfgang), the u-boot comes up fine on the omap3_evm.
I did NOT suggest that. This was just intended as debug hint. We do need this sort.
Best regards,
Wolfgang Denk
Le 01/12/2010 16:17, Sanjeev Premi a écrit :
This patch fixes the linker problems noticed while building the omap3_evm with Codesourcery toolchains 2009q1, 2009q3 and 2010q1.
The compilation was tested as success for both omap3_evm and omap3_beagle with toolchain versions 2009q1 and 2010q1.
[1] http://marc.info/?l=u-boot&m=129104332808386&w=2
Signed-off-by: Sanjeev Premipremi@ti.com
The patch touches all ARMv7 architectures, will need to be reviewed thoroughly.
I am getting hang of relocation feature, but definitely hands-on. Impact would have to be reviewd as well. This is the reason for sending the patch early - before i start testing on the evm.
arch/arm/cpu/armv7/u-boot.lds | 26 +++++++++++++++----------- 1 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/arch/arm/cpu/armv7/u-boot.lds b/arch/arm/cpu/armv7/u-boot.lds index 5725c30..faf6ad8 100644 --- a/arch/arm/cpu/armv7/u-boot.lds +++ b/arch/arm/cpu/armv7/u-boot.lds @@ -55,22 +55,26 @@ SECTIONS
. = ALIGN(4);
.rel.dyn : {
__rel_dyn_start = .;*(.rel*)__rel_dyn_end = .;}
.dynsym : { __dynsym_start = .; *(.dynsym) }
.bss __rel_dyn_start (OVERLAY) : {
__bss_start = .;*(.bss). = ALIGN(4);_end = .;
OVERLAY : NOCROSSREFS
{
.rel.dyn {__rel_dyn_start = .;*(.rel*)__rel_dyn_end = .;}.bss{__bss_start = .;*(.bss). = ALIGN(4);_end = .;}}
/DISCARD/ : { *(.dynstr*) }
Nak -- what we want to overlay is .bss on one hand, and .rel.dyn *plus* .dynsym on the other hand; OVERLAY { ... } does not allow this.
Also, this change modifies the mapping, so if mi makes an obvious bug disappear, it may be only because the resulting u-boot corrupts relocation now in a less obvious way.
Amicalement,
-----Original Message----- From: u-boot-bounces@lists.denx.de [mailto:u-boot-bounces@lists.denx.de] On Behalf Of Albert ARIBAUD Sent: Wednesday, December 01, 2010 10:43 PM To: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
Le 01/12/2010 16:17, Sanjeev Premi a écrit :
This patch fixes the linker problems noticed while building the omap3_evm with Codesourcery toolchains 2009q1, 2009q3 and 2010q1.
The compilation was tested as success for both omap3_evm and omap3_beagle with toolchain versions 2009q1 and 2010q1.
[1] http://marc.info/?l=u-boot&m=129104332808386&w=2
Signed-off-by: Sanjeev Premipremi@ti.com
The patch touches all ARMv7 architectures, will need to be reviewed thoroughly.
I am getting hang of relocation feature, but definitely hands-on. Impact would have to be reviewd as well. This is the reason for sending the patch early - before i start testing on the evm.
arch/arm/cpu/armv7/u-boot.lds | 26 +++++++++++++++----------- 1 files changed, 15 insertions(+), 11 deletions(-)
diff --git a/arch/arm/cpu/armv7/u-boot.lds
b/arch/arm/cpu/armv7/u-boot.lds
index 5725c30..faf6ad8 100644 --- a/arch/arm/cpu/armv7/u-boot.lds +++ b/arch/arm/cpu/armv7/u-boot.lds @@ -55,22 +55,26 @@ SECTIONS
. = ALIGN(4);
.rel.dyn : {
__rel_dyn_start = .;*(.rel*)__rel_dyn_end = .;}
.dynsym : { __dynsym_start = .; *(.dynsym) }
.bss __rel_dyn_start (OVERLAY) : {
__bss_start = .;*(.bss). = ALIGN(4);_end = .;
OVERLAY : NOCROSSREFS
{
.rel.dyn {__rel_dyn_start = .;*(.rel*)__rel_dyn_end = .;}.bss{__bss_start = .;*(.bss). = ALIGN(4);_end = .;}}
/DISCARD/ : { *(.dynstr*) }
Nak -- what we want to overlay is .bss on one hand, and .rel.dyn *plus* .dynsym on the other hand; OVERLAY { ... } does not allow this.
[sp] From the earlier discussion, I inferred the overlay was supposed to be .rel.dyn and .bss.
Let me get the ".rel.dyn + .dynsym" overlay with ".bss".
If it works across compiler versions would that be okay?
~sanjeev
Also, this change modifies the mapping, so if mi makes an obvious bug disappear, it may be only because the resulting u-boot corrupts relocation now in a less obvious way.
Amicalement,
Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Le 01/12/2010 18:19, Premi, Sanjeev a écrit :
Nak -- what we want to overlay is .bss on one hand, and .rel.dyn *plus* .dynsym on the other hand; OVERLAY { ... } does not allow this.
[sp] From the earlier discussion, I inferred the overlay was supposed to be .rel.dyn and .bss.
That's because I avoid saying " .rel.dyn plus .dynsym" and just go for short ".rel.dyn" instead. Sorry for that.
Let me get the ".rel.dyn + .dynsym" overlay with ".bss".
If it works across compiler versions would that be okay?
Getting ".rel.dyn + .dynsym" overlay with ".bss" is exactly what the current linker file does, by emitting .rel.dyn, then .dynsym, then overlaying .bss back at the start of .rel.dyn. Look up a readelf -a of ./u-boot and see where each section starts and ends.
If you find another way to do this overlay yet end up producing a different binary, I'll be interested in the result, but I honestly don't think you will find any.
~sanjeev
Amicalement,
-----Original Message----- From: Albert ARIBAUD [mailto:albert.aribaud@free.fr] Sent: Wednesday, December 01, 2010 11:02 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
Le 01/12/2010 18:19, Premi, Sanjeev a écrit :
Nak -- what we want to overlay is .bss on one hand, and .rel.dyn *plus* .dynsym on the other hand; OVERLAY { ... } does not allow this.
[sp] From the earlier discussion, I inferred the overlay
was supposed
to be .rel.dyn and .bss.That's because I avoid saying " .rel.dyn plus .dynsym" and just go for short ".rel.dyn" instead. Sorry for that.
Let me get the ".rel.dyn + .dynsym" overlay with ".bss".If it works across compiler versions would that be okay?Getting ".rel.dyn + .dynsym" overlay with ".bss" is exactly what the current linker file does, by emitting .rel.dyn, then .dynsym, then overlaying .bss back at the start of .rel.dyn. Look up a readelf -a of ./u-boot and see where each section starts and ends.
[sp] I did the same - but focused only on .rel.dyn and .bss
If you find another way to do this overlay yet end up producing a different binary, I'll be interested in the result, but I honestly don't think you will find any.
[sp] I am trying on this. Getting back to linker scripts after many years. But assuming that there is no way; I am still looking for an explanation on:
1) why the current metod produces different errors across different toolchain versions.
2) How does presence of one variable alone breaks the build? At least, compiler doesn't complain. Even moving it out of .bss by explicit initialization doesn't help. BTW, I verified that it is not used anywhere till end of board_init_f() - didn't go further. Should I?
Can yo help me on these?
~sanjeev
~sanjeev
Amicalement,
Albert.
Le 01/12/2010 19:19, Premi, Sanjeev a écrit :
If you find another way to do this overlay yet end up producing a different binary, I'll be interested in the result, but I honestly don't think you will find any.
[sp] I am trying on this. Getting back to linker scripts after many years. But assuming that there is no way; I am still looking for an explanation on:
1) why the current metod produces different errors across different toolchain versions.
Good question. I know this linker file is exactly the same as for arm926ejs, and I don't get the error with edminiv2 which is arm926ejs based; so it's not only different toolchains, it is also different boards or even different build environments.
2) How does presence of one variable alone breaks the build?
Good question again.
At least, compiler doesn't complain. Even moving it out of .bss by explicit initialization doesn't help. BTW, I verified that it is not used anywhere till end of board_init_f() - didn't go further. Should I?
For the moment we should focus on what happens when we use the current .lds -- it causes a linker error, right? Once we get this sorted out, we'll see if the build actually runs.
Can yo help me on these?
As for the linker error, I am sorry I got a bit lost: I know which toolchains you tried (2010q1 and 2009q1) but not exactly which codebase you build (is it v2010.12-rc2 ? master ? specific patches?) or which board you build. Please refresh me on this, so that I can reproduce the issue locally (I've got 2010q1 already installed).
~sanjeev
Amicalement,
-----Original Message----- From: Albert ARIBAUD [mailto:albert.aribaud@free.fr] Sent: Thursday, December 02, 2010 12:07 AM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
[snip]...[snip]
For the moment we should focus on what happens when we use the current .lds -- it causes a linker error, right? Once we get this sorted out, we'll see if the build actually runs.
Can yo help me on these?As for the linker error, I am sorry I got a bit lost: I know which toolchains you tried (2010q1 and 2009q1) but not exactly which codebase you build (is it v2010.12-rc2 ? master ? specific patches?) or which board you build. Please refresh me on this, so that I can reproduce the issue locally (I've got 2010q1 already installed).
I tried with 2009q1-203, 2009q3-68 and 2010q1-202.
But results with 2009q3 and 2010q1 were same - till I tried all three; so, currently using 2009q1 and 2010q1.
Yes. I was on latest master when I sent patch. Had included the git log as reference for same reason when I got it running.
~sanjeev
Amicalement,
Albert.
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.
Amicalement,
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.
Amicalement,
Dear Albert ARIBAUD,
In message 4CF743E6.60706@free.fr you wrote:
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.
Write access is only in omap3_evm_get_revision() which in turn only gets called in misc_init_r(), i. e. after relocation.
Read access is only in get_omap3_evm_rev() [which is not called outside this file and thus should be made static!] which gets called only in omap3_evm_need_extvbus() which gets acalled only in musb_platform_init(), i. e. during USB init.
This should be safe.
You could try out what happens if you make get_omap3_evm_rev() static...
Best regards,
Wolfgang Denk
Hi Wolfgang,
Le 02/12/2010 08:34, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4CF743E6.60706@free.fr you wrote:
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.
Write access is only in omap3_evm_get_revision() which in turn only gets called in misc_init_r(), i. e. after relocation.
Read access is only in get_omap3_evm_rev() [which is not called outside this file and thus should be made static!] which gets called only in omap3_evm_need_extvbus() which gets acalled only in musb_platform_init(), i. e. during USB init.
This should be safe.
Alright.
You could try out what happens if you make get_omap3_evm_rev() static...
No change: the warning remains, and so do the two segments.
Maybe I should subscribe the binutils list and ask there.
Meanwhile, this variable could be initialized to some safe value such as OMAP3EVM_BOARD_UNKNOWN.
BTW... Why on Earth is it an uint8? Probably a space saving measure, but one I think is not really fruitful, because of probable paddings and alignments; making it an int would allow using smsc_id directly as values for the OMAP3EVM_BOARD_GEN_1 and OMAP3EVM_BOARD_GEN_2...
... plus it removes the linker warning!
I thus suggest turning omap3_evm_version from uint8 to int and get on with debugging the board.
Best regards,
Wolfgang Denk
Amicalement,
Dear Albert ARIBAUD,
In message 4CF74FED.2030102@free.fr you wrote:
BTW... Why on Earth is it an uint8? Probably a space saving measure, but one I think is not really fruitful, because of probable paddings and alignments; making it an int would allow using smsc_id directly as values for the OMAP3EVM_BOARD_GEN_1 and OMAP3EVM_BOARD_GEN_2...
... plus it removes the linker warning!
Oops. Why would this make a difference?
I thus suggest turning omap3_evm_version from uint8 to int and get on with debugging the board.
No, I don't think this is a good idea as it just papers over an existing problem.
Does it help when you change the "*(.bss)" in "arch/arm/cpu/armv7/u-boot.lds" into "*(.*bss)" (so it also includes any .sbss objects) ?
Best regards,
Wolfgang Denk
Le 02/12/2010 09:13, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4CF74FED.2030102@free.fr you wrote:
BTW... Why on Earth is it an uint8? Probably a space saving measure, but one I think is not really fruitful, because of probable paddings and alignments; making it an int would allow using smsc_id directly as values for the OMAP3EVM_BOARD_GEN_1 and OMAP3EVM_BOARD_GEN_2...
... plus it removes the linker warning!
Oops. Why would this make a difference?
Alignement issues, possibly, although we do align the location pointer before the overlay point -- or some bug in the linker.
I thus suggest turning omap3_evm_version from uint8 to int and get on with debugging the board.
No, I don't think this is a good idea as it just papers over an existing problem.
Oh--I did not mean to forget the linker warning thing. Just separate the issues, because I think this particular linker warning is unrelated with getting the board working.
So Sanjeev would change the u8 to an int and proceed with board debug, and I would investigate this issue -- actually, try and find a minimal example that I could go to the binutils list with rather than a full-blown u-boot tree.
Does it help when you change the "*(.bss)" in "arch/arm/cpu/armv7/u-boot.lds" into "*(.*bss)" (so it also includes any .sbss objects) ?
No change.
Best regards,
Wolfgang Denk
Amicalement,
-----Original Message----- From: Albert ARIBAUD [mailto:albert.aribaud@free.fr] Sent: Thursday, December 02, 2010 1:57 PM To: Wolfgang Denk Cc: u-boot@lists.denx.de; Premi, Sanjeev Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
[snip]
So Sanjeev would change the u8 to an int and proceed with board debug,
I will be away from desk for an hour. Will have the patch posted immediately after...
~sanjeev
Hi Sanjeev,
Le 02/12/2010 09:30, Premi, Sanjeev a écrit :
-----Original Message----- From: Albert ARIBAUD [mailto:albert.aribaud@free.fr] Sent: Thursday, December 02, 2010 1:57 PM To: Wolfgang Denk Cc: u-boot@lists.denx.de; Premi, Sanjeev Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
[snip]
So Sanjeev would change the u8 to an int and proceed with board debug,
I will be away from desk for an hour. Will have the patch posted immediately after...
Please let us know the current status of the board, i.e. whether it works or not, and if not, what the console output is.
Amicalement,
-----Original Message----- From: Albert ARIBAUD [mailto:albert.aribaud@free.fr] Sent: Thursday, December 02, 2010 2:12 PM To: Premi, Sanjeev Cc: Wolfgang Denk; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
Hi Sanjeev,
Le 02/12/2010 09:30, Premi, Sanjeev a écrit :
-----Original Message----- From: Albert ARIBAUD [mailto:albert.aribaud@free.fr] Sent: Thursday, December 02, 2010 1:57 PM To: Wolfgang Denk Cc: u-boot@lists.denx.de; Premi, Sanjeev Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
[snip]
So Sanjeev would change the u8 to an int and proceed with board debug,
I will be away from desk for an hour. Will have the patch posted immediately after...
Please let us know the current status of the board, i.e. whether it works or not, and if not, what the console output is.
Just posted the patch. The u-boot comes up on the EVM - only after sort related change in the Makefile. Haven't debuged it yet.
Also noticed a difference between the changes I made yesterday; and your mail - maintaining 'u8' vs. 'int' for the omap3_evm_revision.
~sanjeev
Amicalement,
Albert.
Dear "Premi, Sanjeev",
In message B85A65D85D7EB246BE421B3FB0FBB5930247B9A23B@dbde02.ent.ti.com you wrote:
Just posted the patch. The u-boot comes up on the EVM - only after sort related change in the Makefile. Haven't debuged it yet.
Could you ***please*** be a bit more precise?
What EXACTLY was that "sort related change"?
Do you still need to remove the $(sort) call for the LIBS? That should NOT be done.
Best regards,
Wolfgang Denk
-----Original Message----- From: Wolfgang Denk [mailto:wd@denx.de] Sent: Thursday, December 02, 2010 5:09 PM To: Premi, Sanjeev Cc: Albert ARIBAUD; u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
Dear "Premi, Sanjeev",
In message B85A65D85D7EB246BE421B3FB0FBB5930247B9A23B@dbde02.ent.ti.com you wrote:
Just posted the patch. The u-boot comes up on the EVM - only after sort related change in the Makefile. Haven't debuged it yet.
Could you ***please*** be a bit more precise?
What EXACTLY was that "sort related change"?
Do you still need to remove the $(sort) call for the LIBS? That should NOT be done.
Wolfgang,
I know it shouldn't be done - but just trying to take problem one by one. Unless you want me to report the problems onl after I have a fix for them - and not seek any help.
~sanjeev
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@denx.de You can't evaluate a man by logic alone. -- McCoy, "I, Mudd", stardate 4513.3
Dear "Premi, Sanjeev",
In message B85A65D85D7EB246BE421B3FB0FBB5930247B9A2D5@dbde02.ent.ti.com you wrote:
Do you still need to remove the $(sort) call for the LIBS? That should NOT be done.
...
I know it shouldn't be done - but just trying to take problem one by one. Unless you want me to report the problems onl after I have a fix for them - and not seek any help.
Well, the thing is that I am not convinced that these are really two separate issues. Both seem to have somethign to do with what the linker is doing.
Best regards,
Wolfgang Denk
Dear Albert ARIBAUD,
In message 4CF7583C.7000001@free.fr you wrote:
Does it help when you change the "*(.bss)" in "arch/arm/cpu/armv7/u-boot.lds" into "*(.*bss)" (so it also includes any .sbss objects) ?
No change.
Hm... Maybe it is indeed not a good idea to mix short objects with those requiring larger alignments - we might lose space at best, or case misaligned variables? Eventually it's better to explicitly write
*(.bss*) *(.sbss*)
as we have it in many PowerPC linker scripts (but I have to admit that I don't know if this is really needed - I don't see any .sbss anywhere in this build (I do see them in some objects for PowerPC). For example:
PowerPC:
-> readelf -S common/dlmalloc.o | grep bss [ 3] .bss NOBITS 00000000 000034 000000 00 WA 0 0 1 [36] .bss.n_mmaps_max NOBITS 00000000 002728 000004 00 WA 0 0 4 [37] .sbss.mem_malloc_ NOBITS 00000000 002728 000004 00 WA 0 0 4 [38] .bss.max_total_me NOBITS 00000000 002728 000004 00 WA 0 0 4 [40] .bss.max_sbrked_m NOBITS 00000000 00272c 000004 00 WA 0 0 4 [43] .bss.top_pad NOBITS 00000000 002734 000004 00 WA 0 0 4 [44] .sbss.mem_malloc_ NOBITS 00000000 002734 000004 00 WA 0 0 4 [45] .sbss.mem_malloc_ NOBITS 00000000 002734 000004 00 WA 0 0 4 [46] .bss.current_mall NOBITS 00000000 002734 000028 00 WA 0 0 4
ARM:
-> readelf -S common/dlmalloc.o | grep bss [ 5] .bss NOBITS 00000000 0015e0 000044 00 WA 0 0 4
Best regards,
Wolfgang Denk
-----Original Message----- From: Albert ARIBAUD [mailto:albert.aribaud@free.fr] Sent: Thursday, December 02, 2010 1:21 PM To: Wolfgang Denk Cc: u-boot@lists.denx.de; Premi, Sanjeev Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
Hi Wolfgang,
Le 02/12/2010 08:34, Wolfgang Denk a écrit :
Dear Albert ARIBAUD,
In message4CF743E6.60706@free.fr you wrote:
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.
Write access is only in omap3_evm_get_revision() which in turn only gets called in misc_init_r(), i. e. after relocation.
Read access is only in get_omap3_evm_rev() [which is not called outside this file and thus should be made static!] which gets called only in omap3_evm_need_extvbus() which gets acalled only in musb_platform_init(), i. e. during USB init.
This should be safe.
Alright.
You could try out what happens if you make
get_omap3_evm_rev() static...
No change: the warning remains, and so do the two segments.
Maybe I should subscribe the binutils list and ask there.
Meanwhile, this variable could be initialized to some safe value such as OMAP3EVM_BOARD_UNKNOWN.
One of the things I did to move it away from .bss
BTW... Why on Earth is it an uint8? Probably a space saving measure, but one I think is not really fruitful, because of probable paddings and alignments; making it an int would allow using smsc_id directly as values for the OMAP3EVM_BOARD_GEN_1 and OMAP3EVM_BOARD_GEN_2...
... plus it removes the linker warning!
I thus suggest turning omap3_evm_version from uint8 to int and get on with debugging the board.
Albert,
I have already done this - may not be exactly same. while trying to debug linker script problem; did not want to deviate from the current problem so it is in my working code.
~sanjeev
Best regards,
Wolfgang Denk
Amicalement,
Albert.
-----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.
Dear "Premi, Sanjeev",
In message B85A65D85D7EB246BE421B3FB0FBB5930247AFDACE@dbde02.ent.ti.com you wrote:
1) why the current metod produces different errors across different toolchain versions.
Different tool chains may prvide different quality of optimizations (and bugs), resulting in differnt variable locations. With one memory map you notice immediately if a value gets overwritten, with another you may not notice it.
2) How does presence of one variable alone breaks the build?
It changes the memory map, and thus the location which may get overwritten.
At least, compiler doesn't complain. Even moving it out
How should it? From the tool chain's point of view everything is fine. It's the programmer who did things that lead to trouble; we only get what we deserve.
of .bss by explicit initialization doesn't help.
How exactly did you initialize the variable? Like "int foo = 0;"? Note that this will still go to BSS.
Best regards,
Wolfgang Denk
-----Original Message----- From: Albert ARIBAUD [mailto:albert.aribaud@free.fr] Sent: Wednesday, December 01, 2010 11:02 PM To: Premi, Sanjeev Cc: u-boot@lists.denx.de Subject: Re: [U-Boot] [PATCH] ARMv7: Fix linker errors across toolchain versions
Le 01/12/2010 18:19, Premi, Sanjeev a écrit :
Nak -- what we want to overlay is .bss on one hand, and .rel.dyn *plus* .dynsym on the other hand; OVERLAY { ... } does not allow this.
[sp] From the earlier discussion, I inferred the overlay
was supposed
to be .rel.dyn and .bss.That's because I avoid saying " .rel.dyn plus .dynsym" and just go for short ".rel.dyn" instead. Sorry for that.
Let me get the ".rel.dyn + .dynsym" overlay with ".bss".If it works across compiler versions would that be okay?Getting ".rel.dyn + .dynsym" overlay with ".bss" is exactly what the current linker file does, by emitting .rel.dyn, then .dynsym, then overlaying .bss back at the start of .rel.dyn. Look up a readelf -a of ./u-boot and see where each section starts and ends.
If you find another way to do this overlay yet end up producing a different binary, I'll be interested in the result, but I honestly don't think you will find any.
[sp] Had a quick question - hence separate mail.
Do we really need to preserve section ".dynsym" in the final binary. OR are we okay with single section that contains contents from both?
~sanjeev
~sanjeev
Amicalement,
Albert.
Le 01/12/2010 19:23, Premi, Sanjeev a écrit :
[sp] Had a quick question - hence separate mail.
Do we really need to preserve section ".dynsym" in the final binary. OR are we okay with single section that contains contents from both?
A single section should be OK.
Amicalement,
participants (4)
-
Albert ARIBAUD -
Premi, Sanjeev -
Sanjeev Premi
-
Wolfgang Denk