> Jan Hubicka <hubi...@ucw.cz> writes:
>
> > The problem is that GCC produce constructors/destructors at various places
> > and they all used to be called GLOBAL__I
> > and GLOBAL__D. Then in some cases (on targets that don't have global
> > ctors/dtors or with LTO and ctor/dtor merging)
> > it actually collect them into single constructor function called also
> > GLOBAL__I and GLOBAL__D.
> > Since the first ones are static functions called by the actual constructor,
> > we get problem on targets not having
> > ctors/dtors because collect2 collects even static symbols and attempts to
> > call them from main(). This is reason why
> > I renamed them to be no longer recognized specially.
>
> If I understand you, it sounds like they could have any name at all.
> Just give them a name which doesn't start with _GLOBAL__. Then there
> won't be any problem. Although you should still update the demangler to
> do something sensible with them.
Hmm, this is so anoying :(
I would suggest to wait few days to see if targets arrived into good shape with
what we have right now.
Based on the discussion I guess we have to either
1) return to always inlining and expect that no inlinable stuff ever lands
into constructor (this is I guess easy to disprove with user defined ctor
containing named label or something similar)
We might also give up on merging unlinlinable ctors at LTO time and lose
optimization.
We will get no worse on non-have-cdtors targets then
2) Do the actual renaming of _GLOBAL__I into something else (fully local name
like static_ctor.1234 at a time it is being inserted
into merged ctor.
We can't avoid producing these names early since on target that havecdtors
we avoid producing merged cdtors to avoid need for inlining (and the extra
function when inlining fails)
We can't keep them in symbol table static when they are not constructors as
collect2 is probably not only tool to explode.
Right?
I wonder how hard renaming function is to implement 2)...
Honza
>
> Ian
