Re: [U-Boot] Weak symbols: request for comments
Dear Wolfgang, I have implemented this solution: On 11/05/2010 01:14 PM, Wolfgang Denk wrote: > I think stop using a library archives and do what Linux does > instead is the way to go. > You will find the patch here: http://io.oiioiio.com/~sebc/0001-Use-partial-linking-instead-of-building-library-arch.patch.bz2 I am not posting the patch directly to the list because it is rather large. Feedback is very welcome! Best regards, Sebastien Carlier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Weak symbols: request for comments
Dear Wolfgang, On 11/05/2010 01:23 PM, Wolfgang Denk wrote: > Dear Sebastien Carlier, > > In message<4cd3f58f.8090...@gmail.com> you wrote: > >> It does seem like weak symbols were designed with other uses in mind, >> such as C++ class members defined within a class declaration, or to weak >> the dependencies between libraries... but not really to allow >> overridable definitions (what if two objects want to override the same >> weak symbol in different ways?). >> > Well, but that's exactly why they are used in library code: to allow > overridable definitions. > If this usage were specifically designed for, do you think the linker would silently allow multiple yet conflicting weak definitions for the same symbol? It is true that weak symbols can be used to support overridable definitions, but they seem more suitable for other uses. Regards, Sebastien Carlier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Weak symbols: request for comments
Dear Wolfgang, On 11/05/2010 01:14 PM, Wolfgang Denk wrote: >> 1.1) Stop using weak symbols; use pre-initialized function pointers >>instead (possibly grouped in a struct, for cleanliness). >>This has the benefit of offering a clear interface and being >>independent of toolchain details. >> > And where would the "pre-initialized function pointers" come from? > Without adding a hell of #ifdef's ? > It would not be pretty, and, as pointed out by Joakim Tjernlund, it would not work before relocation. >> 1.2) Use regular (non-weak) extern declarations for overridable stuff; >>collect all default weak symbols into a separate library archive, >>to be supplied last to the linker. >> > Not realy practicable, as the code is distributed all over the place, > and should remain where it logically belongs. > Each module could have its own "defaults.c" for overridable implementations, and the build system could collect all of these. It is not a pain-free solution. >> 1.3) Stop using a library archive for the board specific stuff. >>Instead, collect and link all the object files to produce the >>output binary. Only Makefile changes are involved, but correct >>behavior depends on all boards doing the right thing. >> > Close. I think stop using a library archives and do what Linux does > instead is the way to go. > Partial linking with ld -r ? That does seem like a fairly simple change. Regards, Sebastien Carlier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Weak symbols: request for comments
Dear Sebastien,
>>> Are there better options? Which one would you prefer to see
>>> implemented?
>>>
>> Yes. The old-fashioned #define CONFIG_BOARD_INIT_F and friends
>> method. I would prefer that one. Its not beautiful but still
>> widely used and bullet-proof.
>>
>
> Could you please elaborate? I have looked for things like this in the
> code base but I could not find what you are referring to.
extracts from arch/arm/lib/board.c:
#if defined(CONFIG_ARCH_CPU_INIT)
arch_cpu_init, /* basic arch cpu dependent setup */
#endif
#if defined(CONFIG_BOARD_EARLY_INIT_F)
board_early_init_f,
#endif
#if defined(CONFIG_ARCH_MISC_INIT)
/* miscellaneous arch dependent initialisations */
arch_misc_init ();
#endif
#if defined(CONFIG_MISC_INIT_R)
/* miscellaneous platform dependent initialisations */
misc_init_r ();
#endif
#ifdef BOARD_LATE_INIT
board_late_init ();
#endif
#if defined(CONFIG_RESET_PHY_R)
debug ("Reset Ethernet PHY\n");
reset_phy();
#endif
Just a few that can be "enabled" by board specific defines.
"xxxboard".h #defines them and "xxxboard.c" has to implement them.
Best Regards,
Reinhard
___
U-Boot mailing list
U-Boot@lists.denx.de
http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Weak symbols: request for comments
Dear Sebastien Carlier, In message <4cd3f58f.8090...@gmail.com> you wrote: > > It does seem like weak symbols were designed with other uses in mind, > such as C++ class members defined within a class declaration, or to weak > the dependencies between libraries... but not really to allow > overridable definitions (what if two objects want to override the same > weak symbol in different ways?). Well, but that's exactly why they are used in library code: to allow overridable definitions. > > Yes. The old-fashioned #define CONFIG_BOARD_INIT_F and friends > > method. I would prefer that one. Its not beautiful but still > > widely used and bullet-proof. > > Could you please elaborate? I have looked for things like this in the > code base but I could not find what you are referring to. Don't bother looking for it. We are happy that we have eliminated a bit of the #ifdef mess. We will not add it again. 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: w...@denx.de I had the rare misfortune of being one of the first people to try and implement a PL/1 compiler. -- T. Cheatham ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Weak symbols: request for comments
Dear Reinhard, On 11/05/2010 12:16 PM, Reinhard Meyer wrote: >> 1.2) Use regular (non-weak) extern declarations for overridable stuff; >>collect all default weak symbols into a separate library archive, >>to be supplied last to the linker. >> > Not very practical, that would require that each driver etc. would > be in two parts, the main part and the "weak" part. It would no need > weak functions, however. > You are entirely correct. It would be slightly inconvenient for drivers that provide overridable stuff, but no non-standard feature is needed and the benefit of static linking is preserved. >> 1.3) Stop using a library archive for the board specific stuff. >>Instead, collect and link all the object files to produce the >>output binary. Only Makefile changes are involved, but correct >>behavior depends on all boards doing the right thing. >> > I don't like the "weak" concept :) > It does seem like weak symbols were designed with other uses in mind, such as C++ class members defined within a class declaration, or to weak the dependencies between libraries... but not really to allow overridable definitions (what if two objects want to override the same weak symbol in different ways?). >> 1.4) Link u-boot into a board-agnostic dynamic library, link the >>board-specific stuff into an executable embedding a dynamic >>linker, and package all this stuff somehow. >> > That is too complex. Besides there are few board-agnostic parts in > u-boot, many functions rely in included defines that are board > specific. > Agreed. >> Are there better options? Which one would you prefer to see >> implemented? >> > Yes. The old-fashioned #define CONFIG_BOARD_INIT_F and friends > method. I would prefer that one. Its not beautiful but still > widely used and bullet-proof. > Could you please elaborate? I have looked for things like this in the code base but I could not find what you are referring to. Regards, Sebastien Carlier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Weak symbols: request for comments
Dear Sebastien Carlier, In message <4cd3defc.7010...@gmail.com> you wrote: > > 1.1) Stop using weak symbols; use pre-initialized function pointers > instead (possibly grouped in a struct, for cleanliness). > This has the benefit of offering a clear interface and being > independent of toolchain details. And where would the "pre-initialized function pointers" come from? Without adding a hell of #ifdef's ? > 1.2) Use regular (non-weak) extern declarations for overridable stuff; > collect all default weak symbols into a separate library archive, > to be supplied last to the linker. Not realy practicable, as the code is distributed all over the place, and should remain where it logically belongs. > 1.3) Stop using a library archive for the board specific stuff. > Instead, collect and link all the object files to produce the > output binary. Only Makefile changes are involved, but correct > behavior depends on all boards doing the right thing. Close. I think stop using a library archives and do what Linux does instead is the way to go. > 1.4) Link u-boot into a board-agnostic dynamic library, link the > board-specific stuff into an executable embedding a dynamic > linker, and package all this stuff somehow. Sounds pretty much complicated. 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: w...@denx.de Chapter 1 -- The story so far: In the beginning the Universe was created. This has made a lot of people very angry and been widely regarded as a bad move. ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Weak symbols: request for comments
> > Dear Sebastien Carlier, > > Am 05.11.2010 11:39, schrieb Sebastien Carlier: > > Hello all, > > > So, U-boot needs to be fixed. I can see the following ways forward: > > > > 1.1) Stop using weak symbols; use pre-initialized function pointers > > instead (possibly grouped in a struct, for cleanliness). > > This has the benefit of offering a clear interface and being > > independent of toolchain details. > > sounds good to me despite of grouping. Isn't grouping tough due to > different weak functions for each architecture? This will build more size and relocations and you get fixups too which are/will be bad for code that runs before relocation. Jocke ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Weak symbols: request for comments
Dear Sebastien Carlier, Am 05.11.2010 11:39, schrieb Sebastien Carlier: > Hello all, > So, U-boot needs to be fixed. I can see the following ways forward: > > 1.1) Stop using weak symbols; use pre-initialized function pointers > instead (possibly grouped in a struct, for cleanliness). > This has the benefit of offering a clear interface and being > independent of toolchain details. sounds good to me despite of grouping. Isn't grouping tough due to different weak functions for each architecture? > 1.2) Use regular (non-weak) extern declarations for overridable stuff; > collect all default weak symbols into a separate library archive, > to be supplied last to the linker. sounds messy to me. How about different weak symbols for different architectures? regards Andreas Bießmann ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Weak symbols: request for comments
Dear Sebastien Carlier, > Some context: u-boot uses weak symbols in several places to provide > default definitions intended to be overriden in individual boards; > this feature is broken with recent toolchains (at least gcc 4.4.4, > binutils 2.20.1), and as a result only the default definitions are > used, while board-specific definitions are silently discarded. > > The problem seems to arise because the weak definitions are seen by > the linker before the board-specific ones. The linker will not look > in the board-specific library archive for strong symbols that would > override already defined weak symbols (this behavior is the one > specified by the System V gABI, so it is correct). > > So, U-boot needs to be fixed. I can see the following ways forward: > > 1.1) Stop using weak symbols; use pre-initialized function pointers > instead (possibly grouped in a struct, for cleanliness). > This has the benefit of offering a clear interface and being > independent of toolchain details. Preferable 2nd. Don't use non standard stuff. > > 1.2) Use regular (non-weak) extern declarations for overridable stuff; > collect all default weak symbols into a separate library archive, > to be supplied last to the linker. Not very practical, that would require that each driver etc. would be in two parts, the main part and the "weak" part. It would no need weak functions, however. > > 1.3) Stop using a library archive for the board specific stuff. > Instead, collect and link all the object files to produce the > output binary. Only Makefile changes are involved, but correct > behavior depends on all boards doing the right thing. I don't like the "weak" concept :) > > 1.4) Link u-boot into a board-agnostic dynamic library, link the > board-specific stuff into an executable embedding a dynamic > linker, and package all this stuff somehow. That is too complex. Besides there are few board-agnostic parts in u-boot, many functions rely in included defines that are board specific. > Are there better options? Which one would you prefer to see > implemented? Yes. The old-fashioned #define CONFIG_BOARD_INIT_F and friends method. I would prefer that one. Its not beautiful but still widely used and bullet-proof. Best Regards, Reinhard ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
Re: [U-Boot] Weak symbols: request for comments
Sebastien, [snip] > So, U-boot needs to be fixed. I can see the following ways forward: > > 1.1) Stop using weak symbols; use pre-initialized function pointers >instead (possibly grouped in a struct, for cleanliness). >This has the benefit of offering a clear interface and being >independent of toolchain details. > yep - this is my favorite. Main goal should always be to be as clear as possible. Regards, André MATRIX VISION GmbH, Talstrasse 16, DE-71570 Oppenweiler Registergericht: Amtsgericht Stuttgart, HRB 271090 Geschaeftsfuehrer: Gerhard Thullner, Werner Armingeon, Uwe Furtner ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
[U-Boot] Weak symbols: request for comments
Hello all, I am looking for comments on the use of weak symbols in u-boot. Some context: u-boot uses weak symbols in several places to provide default definitions intended to be overriden in individual boards; this feature is broken with recent toolchains (at least gcc 4.4.4, binutils 2.20.1), and as a result only the default definitions are used, while board-specific definitions are silently discarded. The problem seems to arise because the weak definitions are seen by the linker before the board-specific ones. The linker will not look in the board-specific library archive for strong symbols that would override already defined weak symbols (this behavior is the one specified by the System V gABI, so it is correct). So, U-boot needs to be fixed. I can see the following ways forward: 1.1) Stop using weak symbols; use pre-initialized function pointers instead (possibly grouped in a struct, for cleanliness). This has the benefit of offering a clear interface and being independent of toolchain details. 1.2) Use regular (non-weak) extern declarations for overridable stuff; collect all default weak symbols into a separate library archive, to be supplied last to the linker. 1.3) Stop using a library archive for the board specific stuff. Instead, collect and link all the object files to produce the output binary. Only Makefile changes are involved, but correct behavior depends on all boards doing the right thing. 1.4) Link u-boot into a board-agnostic dynamic library, link the board-specific stuff into an executable embedding a dynamic linker, and package all this stuff somehow. Are there better options? Which one would you prefer to see implemented? For reference, here is the list of the definitions currently marked weak in the u-boot code: _machine_restart arch_memory_failure_handle arch_memory_test_advance arch_memory_test_cleanup arch_memory_test_prepare board_hwconfig board_nand_init board_reset cpu_hwconfig do_bootelf_exec do_go_exec getDebugChar kgdb_flush_cache_all kgdb_flush_cache_range kgdb_interruptible kgdb_serial_init mg_get_drv_data putDebugChar putDebugStr read_fifo spi_cs_activate spi_cs_deactivate spi_cs_is_valid system_map -- Sebastien Carlier ___ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
