Re: [U-Boot] [PATCH v1] Refactor linker-generated arrays
Hi Albert,
On 02/16/2013 07:20 PM, Albert ARIBAUD wrote:
Hi Andreas,
On Mon, 04 Feb 2013 13:41:09 +0100, Andreas Bießmann
andreas.de...@googlemail.com wrote:
Hi Albert,
On 02.02.2013 18:02, Albert ARIBAUD wrote:
snip strict aliasing error on gcc-4.4
I have dug into it and found a way to avoid GCC 4.4 or below to warn
about aliasing, by replacing 'struct {}' with 'char[0]' as the
0-byte-size type.
I still have some warnings through, regarding some regions not being
declared:
avr32-ld:built in linker script:15: warning: memory region `FLASH' not
declared
avr32-ld:built in linker script:69: warning: memory region
`CPUSRAM' not declared
I assume you use Mike Frysingers precompiled avr32 toolchain. I know
about that warnings and beware, these toolchain produce defective
binaries! The u-boot does not relocate itself properly with these newlib
toolchains (also the atmel provided one).
It appears 'normal' in that without my patch, the same error occurs;
but I'd prefer that you confirm whether you have the same warnings on
your side.
It's ok so far, the arm-linux toolchain I have do not produce these
warnings. Kan you provide the patch so I will do a runtime test.
Best regards
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1] Refactor linker-generated arrays
On 02/18/2013 11:39 AM, Andreas Bießmann wrote: Hi Albert, On 02/16/2013 07:20 PM, Albert ARIBAUD wrote: snip It's ok so far, the arm-linux toolchain I have do not produce these I mean avr32-linux ... damn weekend ... ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1] Refactor linker-generated arrays
Hi Andreas, On Mon, 18 Feb 2013 11:42:07 +0100, Andreas Bießmann andreas.de...@googlemail.com wrote: On 02/18/2013 11:39 AM, Andreas Bießmann wrote: Hi Albert, On 02/16/2013 07:20 PM, Albert ARIBAUD wrote: snip It's ok so far, the arm-linux toolchain I have do not produce these I mean avr32-linux ... damn weekend ... Thanks Andreas for the feedback. I am currently testing V2 locally and will send it out in a few hours hopefully. Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1] Refactor linker-generated arrays
Hi Andreas,
On Mon, 04 Feb 2013 13:41:09 +0100, Andreas Bießmann
andreas.de...@googlemail.com wrote:
Hi Albert,
On 02.02.2013 18:02, Albert ARIBAUD wrote:
Refactor linker-generated array code so that symbols
which were previously linker-generated are now compiler-
generated. This causes relocation records of type
R_ARM_ABS32 to become R_ARM_RELATIVE, which makes
code which uses LGA able to run before relocation as
well as after.
Note: this affects more than ARM targets, as linker-
lists span possibly all target architectures, notably
PowerPC.
Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
Tested on avr32. The patch seems to work (basic shell testing), however
it generates an aliasing warning:
---8---
abiessmann@azuregos % PATH=$AVR32_PATH:$PATH BUILD_DIR=/tmp/build_avr32
MAKEALL_LOGDIR=/tmp/LOG BUILD_NCPUS=4 BUILD_NBUILDS=4 ./MAKEALL atstk1002
Configuring for atstk1002 board...
text data bss dec hex filename
116315 8972 211900 337187 52523
/tmp/build_avr32/atstk1002/u-boot
env_callback.c: In function 'find_env_callback':
env_callback.c:47: warning: dereferencing pointer 'clbkp' does break
strict-aliasing rules
env_callback.c:44: note: initialized from here
env_callback.c:46: note: initialized from here
---8---
I think it has something to do with tha fact that you re-cast the
anonymous struct 'start' here:
---8---
#define ll_entry_start(_type, _list)
({
static struct {} start __aligned(4) __attribute__((unused,
section(.u_boot_list_2_#_list_1)));
(_type *)start;
})
---8---
I think other gcc-4.4 users will see the same error. Currently I have no
time to dive into this.
I have dug into it and found a way to avoid GCC 4.4 or below to warn
about aliasing, by replacing 'struct {}' with 'char[0]' as the
0-byte-size type.
I still have some warnings through, regarding some regions not being
declared:
avr32-ld:built in linker script:15: warning: memory region `FLASH' not
declared
avr32-ld:built in linker script:69: warning: memory region
`CPUSRAM' not declared
It appears 'normal' in that without my patch, the same error occurs;
but I'd prefer that you confirm whether you have the same warnings on
your side.
Best regards
Andreas Bießmann
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1] Refactor linker-generated arrays
Hello Albert, On 02.02.2013 18:02, Albert ARIBAUD wrote: Refactor linker-generated array code so that symbols which were previously linker-generated are now compiler- generated. This causes relocation records of type R_ARM_ABS32 to become R_ARM_RELATIVE, which makes code which uses LGA able to run before relocation as well as after. Note: this affects more than ARM targets, as linker- lists span possibly all target architectures, notably PowerPC. Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net --- for arm926ejs Tested-by: Heiko Schocher h...@denx.de Just one minor comment ... [...] diff --git a/common/command.c b/common/command.c index 50c8429..6ac59e4 100644 --- a/common/command.c +++ b/common/command.c @@ -507,6 +507,7 @@ static int cmd_call(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) int result; result = (cmdtp-cmd)(cmdtp, flag, argc, argv); + remove this Codingstyle change please. bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1] Refactor linker-generated arrays
Hi Heiko, On Mon, 04 Feb 2013 09:21:02 +0100, Heiko Schocher h...@denx.de wrote: Hello Albert, On 02.02.2013 18:02, Albert ARIBAUD wrote: Refactor linker-generated array code so that symbols which were previously linker-generated are now compiler- generated. This causes relocation records of type R_ARM_ABS32 to become R_ARM_RELATIVE, which makes code which uses LGA able to run before relocation as well as after. Note: this affects more than ARM targets, as linker- lists span possibly all target architectures, notably PowerPC. Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net --- for arm926ejs Tested-by: Heiko Schocher h...@denx.de Thanks! Just one minor comment ... [...] diff --git a/common/command.c b/common/command.c index 50c8429..6ac59e4 100644 --- a/common/command.c +++ b/common/command.c @@ -507,6 +507,7 @@ static int cmd_call(cmd_tbl_t *cmdtp, int flag, int argc, char * const argv[]) int result; result = (cmdtp-cmd)(cmdtp, flag, argc, argv); + remove this Codingstyle change please. Sorry, should have triple-checked that -- this single blank line change in common/command.c stems from ad hoc code I'd added here for test purposes when the patch was only proof-of-concept. Will fix in V2. bye, Heiko Amicalement, -- Albert. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1] Refactor linker-generated arrays
Hi Albert,
On 02.02.2013 18:02, Albert ARIBAUD wrote:
Refactor linker-generated array code so that symbols
which were previously linker-generated are now compiler-
generated. This causes relocation records of type
R_ARM_ABS32 to become R_ARM_RELATIVE, which makes
code which uses LGA able to run before relocation as
well as after.
Note: this affects more than ARM targets, as linker-
lists span possibly all target architectures, notably
PowerPC.
Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
Tested on avr32. The patch seems to work (basic shell testing), however
it generates an aliasing warning:
---8---
abiessmann@azuregos % PATH=$AVR32_PATH:$PATH BUILD_DIR=/tmp/build_avr32
MAKEALL_LOGDIR=/tmp/LOG BUILD_NCPUS=4 BUILD_NBUILDS=4 ./MAKEALL atstk1002
Configuring for atstk1002 board...
textdata bss dec hex filename
1163158972 211900 337187 52523 /tmp/build_avr32/atstk1002/u-boot
env_callback.c: In function 'find_env_callback':
env_callback.c:47: warning: dereferencing pointer 'clbkp' does break
strict-aliasing rules
env_callback.c:44: note: initialized from here
env_callback.c:46: note: initialized from here
---8---
I think it has something to do with tha fact that you re-cast the
anonymous struct 'start' here:
---8---
#define ll_entry_start(_type, _list)
({
static struct {} start __aligned(4) __attribute__((unused,
section(.u_boot_list_2_#_list_1)));
(_type *)start;
})
---8---
I think other gcc-4.4 users will see the same error. Currently I have no
time to dive into this.
Best regards
Andreas Bießmann
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1] Refactor linker-generated arrays
Hi Andreas,
On Mon, 04 Feb 2013 13:41:09 +0100, Andreas Bießmann
andreas.de...@googlemail.com wrote:
Hi Albert,
On 02.02.2013 18:02, Albert ARIBAUD wrote:
Refactor linker-generated array code so that symbols
which were previously linker-generated are now compiler-
generated. This causes relocation records of type
R_ARM_ABS32 to become R_ARM_RELATIVE, which makes
code which uses LGA able to run before relocation as
well as after.
Note: this affects more than ARM targets, as linker-
lists span possibly all target architectures, notably
PowerPC.
Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
Tested on avr32. The patch seems to work (basic shell testing), however
it generates an aliasing warning:
---8---
abiessmann@azuregos % PATH=$AVR32_PATH:$PATH BUILD_DIR=/tmp/build_avr32
MAKEALL_LOGDIR=/tmp/LOG BUILD_NCPUS=4 BUILD_NBUILDS=4 ./MAKEALL atstk1002
Configuring for atstk1002 board...
text data bss dec hex filename
116315 8972 211900 337187 52523
/tmp/build_avr32/atstk1002/u-boot
env_callback.c: In function 'find_env_callback':
env_callback.c:47: warning: dereferencing pointer 'clbkp' does break
strict-aliasing rules
env_callback.c:44: note: initialized from here
env_callback.c:46: note: initialized from here
---8---
I think it has something to do with tha fact that you re-cast the
anonymous struct 'start' here:
---8---
#define ll_entry_start(_type, _list)
({
static struct {} start __aligned(4) __attribute__((unused,
section(.u_boot_list_2_#_list_1)));
(_type *)start;
})
---8---
Thanks Andreas for bringing this to my attention -- I'm surprised that
there's only one such warning, though, as there are may such casts. I'll
get my hands on a 4.4 compiler and try to find a way to cleanly avoid
the warning.
I think other gcc-4.4 users will see the same error. Currently I have no
time to dive into this.
Don't bother. I'll do the diving. :)
Best regards
Andreas Bießmann
Amicalement,
--
Albert.
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1] Refactor linker-generated arrays
Hello Albert, On 02.02.2013 18:02, Albert ARIBAUD wrote: Refactor linker-generated array code so that symbols which were previously linker-generated are now compiler- generated. This causes relocation records of type R_ARM_ABS32 to become R_ARM_RELATIVE, which makes code which uses LGA able to run before relocation as well as after. Just tested this patch and it solves my ll_entry_* work only after relocation problem posted here: http://lists.denx.de/pipermail/u-boot/2013-February/145711.html Will test it deeper on monday, thanks! bye, Heiko -- DENX Software Engineering GmbH, MD: Wolfgang Denk Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1] Refactor linker-generated arrays
Hi Albert,
2013/2/2 Albert ARIBAUD albert.u.b...@aribaud.net:
Refactor linker-generated array code so that symbols
which were previously linker-generated are now compiler-
generated. This causes relocation records of type
R_ARM_ABS32 to become R_ARM_RELATIVE, which makes
code which uses LGA able to run before relocation as
well as after.
Note: this affects more than ARM targets, as linker-
lists span possibly all target architectures, notably
PowerPC.
Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
---
for the MIPS part:
Tested-by: Daniel Schwierzeck daniel.schwierz...@gmail.com
BTW: if we use
.u_boot_list : {
KEEP(*(SORT(.u_boot_list*)))
}
we can get rid of the undef magic in the final link of u-boot
--- a/Makefile
+++ b/Makefile
@@ -559,10 +559,8 @@ GEN_UBOOT = \
$(PLATFORM_LIBS) -Wl,-Map -Wl,u-boot.map -o u-boot
else
GEN_UBOOT = \
- UNDEF_LST=`$(OBJDUMP) -x $(LIBBOARD) $(LIBS) | \
- sed -n -e
's/.*\($(SYM_PREFIX)_u_boot_list_.*\)/-u\1/p'|sort|uniq`;\
cd $(LNDIR) $(LD) $(LDFLAGS) $(LDFLAGS_$(@F)) \
- $$UNDEF_LST $(__OBJS) \
+ $(__OBJS) \
--start-group $(__LIBS) --end-group $(PLATFORM_LIBS) \
-Map u-boot.map -o u-boot
endif
--
Best regards,
Daniel
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1] Refactor linker-generated arrays
Dear Daniel Schwierzeck,
Hi Albert,
2013/2/2 Albert ARIBAUD albert.u.b...@aribaud.net:
Refactor linker-generated array code so that symbols
which were previously linker-generated are now compiler-
generated. This causes relocation records of type
R_ARM_ABS32 to become R_ARM_RELATIVE, which makes
code which uses LGA able to run before relocation as
well as after.
Note: this affects more than ARM targets, as linker-
lists span possibly all target architectures, notably
PowerPC.
Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net
---
for the MIPS part:
Tested-by: Daniel Schwierzeck daniel.schwierz...@gmail.com
BTW: if we use
.u_boot_list : {
KEEP(*(SORT(.u_boot_list*)))
}
we can get rid of the undef magic in the final link of u-boot
UU, that's amazing. We're shifting from one kind of black magic onto
another
voodoo. But certainly, this KEEP() is much cleaner, I like it :)
Best regards,
Marek Vasut
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] [PATCH v1] Refactor linker-generated arrays
Hello Albert, On 02/02/2013 06:02 PM, Albert ARIBAUD wrote: Refactor linker-generated array code so that symbols which were previously linker-generated are now compiler- generated. This causes relocation records of type R_ARM_ABS32 to become R_ARM_RELATIVE, which makes code which uses LGA able to run before relocation as well as after. Note: this affects more than ARM targets, as linker- lists span possibly all target architectures, notably PowerPC. Signed-off-by: Albert ARIBAUD albert.u.b...@aribaud.net --- Command completion currently traps with U-Boot master on a twister board, as mentioned in [1]. Depending on random, valid changes in the code, the name pointers in the command list can become corrupted. Although this patch shouldn't effect code running after relocation, it does prevent the incorrect pointers and solves mentioned problem. The exact reason is unknown, but it might be that code running before relocation corrupts the data used after relocation. At least this patch fixes the behaviour for the twister and prevents that I get completely insane, thanks! For the twister: Tested-by: Jeroen Hofstee jhofs...@myspectrum.nl Thanks, Jeroen [1] http://lists.denx.de/pipermail/u-boot/2013-February/145709.html ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
