[Bug ld/22762] missing static variable constructor calls

[martin at martin dot st]

https://sourceware.org/bugzilla/show_bug.cgi?id=22762

Martin Storsjö <martin at martin dot st> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |martin at martin dot st

--- Comment #15 from Martin Storsjö <martin at martin dot st> ---
(In reply to Hannes Domani from comment #12)
> (In reply to Nick Clifton from comment #9)
> > Well I have been wracking my brains for a couple of days now, and I cannot
> > think of a better solution either.
> You first suggested this:
> > This would imply that the placement of the __CTOR_LIST__ symbol in
> > libgcc(_ctors.o) is incorrect,
> So is the definition in libgcc2.c even necessary, isn't it always provided
> by the linker?

It's not normally needed, no. As far as I understand it, I think libgcc just
provides the symbol in case nothing else provides it (maybe for other targets
than mingw).

> On the other hand, I don't know why anyone would want to override
> __CTOR_LIST__ anyways.

This issue originated from trying to use mingw-w64 with lld, llvm's linker
(which basically works like msvc's link.exe with a few additions), and doesn't
provide __CTOR_LIST__ and doesn't use linker scripts at all.

When intending to use that linker, we provide __CTOR_LIST__ within mingw-w64's
crt startup object files. If binutils ld would be able to handle this case
(which the original patch achieves), it would (at a later stage when one could
start requiring binutils >= 2.30) reduce the amount of conditionals and the
fact that we need to know what linker we're going to use, when building
mingw-w64.

If we'd enable this codepath for all cases, we'd fix this issue for binutils
2.30 (but at the same time break all earlier versions).

Other potential ways of handling it would be to extend libgcc's fallback
__CTOR_LIST__ to something like this:

__attribute__ (( __section__ (".ctors"), __used__ , aligned(sizeof(void *))))
const void * __CTOR_LIST__ = (void *) -1;  
__attribute__ (( __section__ (".dtors"), __used__ , aligned(sizeof(void *))))
const void * __DTOR_LIST__ = (void *) -1;  
__attribute__ (( __section__ (".ctors.99999"), __used__ , aligned(sizeof(void
*)))) const void * __CTOR_END__ = (void *) 0;  
__attribute__ (( __section__ (".dtors.99999"), __used__ , aligned(sizeof(void
*)))) const void * __DTOR_END__ = (void *) 0;  

However I think that only works if the object file that provides it (in the
case of mingw-w64 for lld, in crt2.o) is linked first, before everything else,
placing __CTOR_LIST__ at the head of the .ctors section. And I don't think
that's fit for libgcc since I guess it's too target specific, and would still
cause breakage for any current libgcc version that doesn't have it.

So given that, I guess reverting the patch is the most sensible thing to do,
and we'll have to start over with other approaches, if we want to unify
matters.

-- 
You are receiving this mail because:
You are on the CC list for the bug.