From: Sebastien Carlier <sebastien.carlier@gmail.com>
To: u-boot@lists.denx.de
Subject: [U-Boot] Weak symbols: request for comments
Date: Fri, 05 Nov 2010 11:39:56 +0100 [thread overview]
Message-ID: <4CD3DEFC.7010104@gmail.com> (raw)
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
next reply other threads:[~2010-11-05 10:39 UTC|newest]
Thread overview: 23+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-11-05 10:39 Sebastien Carlier [this message]
2010-11-05 11:01 ` [U-Boot] Weak symbols: request for comments Andre Schwarz
2010-11-05 11:16 ` Reinhard Meyer
2010-11-05 12:16 ` Sebastien Carlier
2010-11-05 12:23 ` Wolfgang Denk
2010-11-05 12:57 ` Sebastien Carlier
2010-11-06 14:28 ` [U-Boot] [PATCH] Switch from library archives to partial linking Sebastien Carlier
2010-11-06 17:21 ` Albert ARIBAUD
2010-11-07 14:16 ` Peter Tyser
2010-11-07 15:11 ` Sebastien Carlier
2010-11-07 15:30 ` Andreas Bießmann
2010-11-07 16:18 ` Sebastien Carlier
2010-11-07 16:54 ` Andreas Bießmann
2010-11-10 4:41 ` Mike Frysinger
2010-11-07 21:46 ` Wolfgang Denk
2010-11-07 22:24 ` Peter Tyser
2010-11-07 22:33 ` Wolfgang Denk
2010-11-05 12:30 ` [U-Boot] Weak symbols: request for comments Reinhard Meyer
2010-11-05 11:21 ` Andreas Bießmann
2010-11-05 12:04 ` Joakim Tjernlund
2010-11-05 12:14 ` Wolfgang Denk
2010-11-05 12:40 ` Sebastien Carlier
2010-11-05 15:00 ` Sebastien Carlier
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4CD3DEFC.7010104@gmail.com \
--to=sebastien.carlier@gmail.com \
--cc=u-boot@lists.denx.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox