[U-Boot] Weak symbols: request for comments

[Reinhard Meyer <u-boot@emk-elektronik.de>]

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