Danny Smith wrote:
> As it turns out, __declspec(selectany) is relatively easy to implement in gcc,
> and the gas assembler already knows what to do with the section flags.
>
> Is this a desired feature? In a way, it can serve as a replacement for weak
> definitions of global variables. Or should we pursue the Linux/GLIBC semantics
> for weak definitions.
Yes, I would love to see __declspec(selectany) supported analogously to
how MSVC supports it.
I think it would be best keeping weak declarations as weak symbols,
orthogonal from COMDAT sections. This allows the two to be mixed and
matched as appropriate, and also remains closest to Linux, which now as
both weak symbols and PE-style common sections.
I've been getting quite a lot of unexpected feedback from all sorts of
projects with regards to the weak symbol changes in binutils CVS. It
turns out quite a lot of projects were waiting on weak symbols to make
their Windows ports work.
(However, I get the feeling that there is a lot of misuse and
misunderstanding about exactly what weak symbols do. Its my suspicion
that a lot of projects have older legacy code that uses weak symbols,
and many maintainers feel uncomfortable changing the code.)
This "difference in semantics" is turning out to be a bigger deal than I
thought. Since the Linux ELF (from System V, I think) semantics aren't
documented anywhere, and there is actually no good reason to use these
semantics, and because PECOFF doesn't implement them, I didn't think it
would be a very big deal at all. However, feedback is telling me otherwise.
Theres actually a few differences in semantics, but I am convinced at
noone will notice any of them except for one. This is also the only
difference (as far as I know) that is visible using GCC's "weak" or
"weak, alias" attributes. (The others are only visible when writing
assembler code.)
The difference is specifically that weak symbols do not link with
symbols of the same name in other translation units. This is what
PECOFF says, to the best of my understanding, and this is what MS LINK
actually does. If this behavior is changed in binutils, there are two
consequences:
1) Some measure of error checking is lost, for people intending to use
PECOFF-style symbols.
2) Code that assumes the extended semantics will not work with the
Microsoft linker, or anyone else's PE linker.
However, I think these are reasonable prices to pay. Changing this
feature would, to the best of my knowledge, bring binutils PECOFF weak
symbols into alignment with Linux weak symbols. It would also be
compatible with all code that correctly uses PECOFF-style weak symbols.
This proposed extension is not in violation of the PECOFF standard, either.
It's also possible that a warning or "informational message" such as
emitted for auto-import could be used, to retain the diagnostic checking
of the official semantics. Or perhaps an option could be added to the
linker to toggle semantics.
So, would altering the semantics of weak symbols in binutils in this
manner, and continuing to have GCC's weak attribute refer to weak
symbols, be the most appropriate course of action? If so, would any of
the suggestions in the last paragraph be appropriate?
Sorry for the length--I am too short on time to write a shorter message.
Aaron W. LaFramboise
|
