egcc 1.1.2 outputs global object constructors as local (C static) symbols

Martin v. Loewis
Fri Apr 30 23:15:00 GMT 1999

> This would really solves the problem without requiring gcc modification
> exported_symbol_ctor_table ctor_table {
>    {function_pointer, original_symbol_name},
>    ...
>    {0, 0}
> };

You can use the relevant code from crtstuff:

asm ("section .ctors,\"aw\"\n");
void* exported_symbol_ctor_table[0];

in the first object file, and

asm ("section .ctors,\"aw\"\n");
void* exported_symbol_ctor_table_end[0] = { 0 };

in the last object file. You don't get the symbol name, though.

> NB : the original_symbol_name may be REQUIRED to use proprietary
>      constructor ordering technic based on symbol name and would
>      remove the need of some GNU C++ extension like pragma for
>      ordering constructors...

Here we go again :-( This is not supported; it is either the approach
above, or you change gcc. Alternatively, you have to elaborate what
the scheme is and why you require it to work it exactly that way.

Please note that the name generated for the _GLOBAL_ function might
change without notice from one gcc release to another; it is nothing
to rely on. Whatever your scheme is, it probably has the problem:

if more than one object is created in a translation unit, you can't
give different priorities to them.

Whatever the scheme is, you probably can achive the same effect by
linking the object files in the right order, and perhaps putting more
.ctors slots in between object files if necessary.


More information about the Gcc-bugs mailing list