Hi!
As indicated in other mails, we now have support for gcc-style constructors in OsmocomBB. The way to use them is relatively easy: Simply put "__attribute__((constructor))" at the function that you want to be called during initialization.
The way how this works is like this: * gcc and the linker create a table of function pointers to all the functions with that attribute * the code in compal_ramload_start.S takes care of calling lib/ctors.s:do_global_ctors() which iterates over the list and calls each constructor
This concept is now used for things like prim_fbsb_init() in layer1, but I have also started to use it for board_init(). This means that board_init() no longer needs to be called from the main() function of each app.
We can probably put more stuff into constructors, but we should also be careful as with gcc-4.0.2 we cannot yet indicate priorities and thus there is no explicit way to control the ordering in case of dependencies.
Regards, Harald
Hi,
If I understand correctly, this is the same type of idea of the linux kernel's __init magic, except that no code cleanup is done?
Regards Sebastien
On Fri, Jun 25, 2010 at 3:28 AM, Harald Welte laforge@gnumonks.org wrote:
Hi!
As indicated in other mails, we now have support for gcc-style constructors in OsmocomBB. The way to use them is relatively easy: Simply put "__attribute__((constructor))" at the function that you want to be called during initialization.
The way how this works is like this:
- gcc and the linker create a table of function pointers to all the
functions with that attribute
- the code in compal_ramload_start.S takes care of calling
lib/ctors.s:do_global_ctors() which iterates over the list and calls each constructor
This concept is now used for things like prim_fbsb_init() in layer1, but I have also started to use it for board_init(). This means that board_init() no longer needs to be called from the main() function of each app.
We can probably put more stuff into constructors, but we should also be careful as with gcc-4.0.2 we cannot yet indicate priorities and thus there is no explicit way to control the ordering in case of dependencies.
Regards, Harald --
- Harald Welte laforge@gnumonks.org
============================================================================ "Privacy in residential applications is a desirable marketing option." (ETSI EN 300 175-7 Ch. A6)
On 06/28/2010 04:19 PM, Sébastien Lorquet wrote:
Hi,
If I understand correctly, this is the same type of idea of the linux kernel's __init magic, except that no code cleanup is done?
AFAIK it is the same type of idea but implemented in a different way: the linux kernel uses several (self-defined) sections, see http://lxr.free-electrons.com/source/include/linux/init.h lines 170ff. (and 187ff.)
#define __define_initcall(level,fn,id) \ static initcall_t __initcall_##fn##id __used \ __attribute__((__section__(".initcall" level ".init"))) = fn
to define the init functions and the order they should be called in.
Cheers, Jörg.
On Mon, Jun 28, 2010 at 04:19:01PM +0200, Sébastien Lorquet wrote:
Hi,
If I understand correctly, this is the same type of idea of the linux kernel's __init magic, except that no code cleanup is done?
It is similar in concept/iea, but as indicated we align the implementation closer to what the GNU GCC C++ runtime does.
baseband-devel@lists.osmocom.org
-
Harald Welte -
Joerg Albert -
Sébastien Lorquet