From: Danny S. <dan...@cl...> - 2005-02-14 07:31:19
|
Hi, 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. The work that Aaron did with binutils to get "weak externals" working only applied to undefined weaks -- ie, declaration of externally defined symbols as weak. Defining symbols with weak attribute in multiple translation units compiles and links without error but crashes at runtme. I suppose, that needs a GCC patch to warn or error about such definitions. I have a patch fo gcc for selectany , which I will probably submit once the trunk has branched (new features are disallowed during this stage of GCC development cycle). I still need to write the documentation, but that should be pretty easy since it is described well in PECOFF 60 specs and in MSDN docs.. Danny |
From: Aaron W. L. <aar...@aa...> - 2005-02-14 08:02:13
|
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 |
From: Earnie B. <ea...@us...> - 2005-02-14 11:45:43
|
<quote who="Aaron W. LaFramboise"> > 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. > Gets my vote. > > 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. > I suggest providing both with the default being PECOFF. I clearly see two sets of MinGW users. Those that want MS semantics and those that would prefer Linux semantics as much as possible. Earnie -- http://www.mingw.org http://sourceforge.net/projects/mingw https://sourceforge.net/donate/index.php?user_id=15438 |