On 11/07/13 08:44, Stefan Kristiansson wrote: > Hi all, > > Thanks to Sebastian Macke it was discovered that the constructors > and destructors in dynamic loaded libraries were never executed. > After some more investigation, it became clear that not even __init and > __fini were execute. > The dynamic linker performs init/fini execution by looking for the > DT_INIT/DT_FINI elements in the dynamic library and what is found > there is executed [1][2]. > The problem now was that DT_INIT/DT_FINI elements were never inserted into > the dynamic library and the reason for that is that GNU linker expects > the init and fini function names to be _init and _fini and not __init and > __fini [3]. > > AFAICT, there are two options to solve this: > 1) rename our __init and __fini functions to _init and _fini > 2) set link_info.init_function to __init and link_info.fini_function to __fini > ere > I think 1) is the path to take, mostly because that is the naming that most > architectures follow and none does 2).
Hi Stefan, I asked Joern about this (copied) to check that that it didn't also affect the old 4.5.1 compiler. He believes this problem does not occur there. He pointed me to the C++ standard, which I guess you already know about; >From the 2003 C++ standard (which I understand didn't change in 2011): 17.4.3.2.1 Global names [lib.global.names] Certain sets of names and function signatures are always reserved to the implementation: Each name that contains a double underscore (_ _) or begins with an underscore followed by an uppercase letter (2.11) is reserved to the implementation for any use. Each name that begins with an underscore is reserved to the implementation for use as a name in the global namespace [165]. [165] Such names are also reserved in namespace ::std (17.4.3.1). By my reading, this means that either of your approaches is OK, since _init and _fini should be in the global namespace. Thanks for fixing this. Best wishes, Jeremy > Following this mail comes a set of patches that I intend to commit to > uClibc, binutils and gcc unless someone has any objections or better ideas > to solve this. > It might not be strictly necessary to do the change in all of those > repositories, but I think it's worth being consistent on this. > > Stefan > > [1] > https://github.com/openrisc/uClibc-or1k/blob/master/ldso/libdl/libdl.c#L636 > [2] > https://github.com/openrisc/uClibc-or1k/blob/master/ldso/libdl/libdl.c#L845 > [3] https://github.com/openrisc/or1k-src/blob/or1k/ld/ldmain.c#L288 > _______________________________________________ > Openrisc mailing list > [email protected] > http://lists.opencores.org/listinfo/openrisc > -- Tel: +44 (1590) 610184 Cell: +44 (7970) 676050 SkypeId: jeremybennett Email: [email protected] Web: www.embecosm.com Twitter: @embecosm _______________________________________________ OpenRISC mailing list [email protected] http://lists.openrisc.net/listinfo/openrisc
