From: jeffdbREMOVETHIS AT netzone DOT com (Mikey) Subject: Re: egcs update: PE linker problem work-around 29 Oct 1997 17:59:20 -0800 Message-ID: <3457d617.744989.cygnus.gnu-win32@smtp.netzone.com> References: <9710290640 DOT AA04997 AT modi DOT xraylith DOT wisc DOT edu> Reply-To: jeffdbREMOVETHIS AT netzone DOT com Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit To: Mumit Khan , gnu-win32 AT cygnus DOT com, ian AT cygnus DOT com You are correct, ld (actually the ld/bfd interface) does not properly handle comdat sections the Communal; sym=XXX is not recognized (I guess there was no way to fit it into bfd?), nor is the associated section attribute recognized. (at least I couldn't find them looking through the code, and objdump dosen't seem to know about them) There are quite a few binary incompatibilities like this left between cygwin32 and MS pei that need to be corrected, but it has been so long since the last release, that I hesitate to spend time on fixes that will have to be completely rewritten when the next version comes out. Also since what we are waiting for right now (I assume ;^) is a rewrite of the bfd backend for pei to accommodate section relative symbols, Ian may already be fixing some of them. Following is a list of the ones I have spotted, in trying to rewrite the mingw32 startup files to be more MS compatible, this is not exhaustive, just the ones I have spotted ;^) 2. The pick associative section attribute isn't implemented at all in cygwin32 ld? (dosen't necessarily need to be in gcc, but to link MS lib's it is a must) 3. Import stubs in Import libraries need to be named to the name of the exporting dll/exe CAPITOLIZED, as that is the only way to distinguish a regular .obj or .o file from a stub. (maybe Communal sym?) (this is completely undoc, but I could find no other differences) 4. The SEC_LINK_ONCE flag handling needs to be rewritten for Import stubs, except for SEC_LINK_ONCE_DISCARD, (idata 4&6) since abfd will be the same for all 5 idata$7 dosen't exist, and needs to be eliminated, import dll belongs in idata$6 of head. 6 DATA keyword for .def files needs to be added (does not create a thunk or unprefixed symbol only the _imp__), The CONSTANT keyword need to be changed so as not to create a thunk (.text) section. 7 CC1 needs to be fixed to allow __attribute__ ((_stdcall)) between * and funcname 8 -freg-struct-return is the default for CL.EXE, and should be changed to the default for gcc.exe 9 One of the main reasons for problems linking with .lib files, is that microsoft uses _imp__ instead of __imp_ in their stub libraries, how could this have gone unnoticed? lines 1587, 1588, 1843, 1844, 1854, and 1962 of dlltool.c in .../cdk/binutils need to be corrected. 10. dllimport & dllexport attributes need to be copied from .../cdk/gcc/config/arm/pe.[ch] to the appropriate places in .../cdk/gcc/config/i386/* On Wed, 29 Oct 1997 00:40:31 -0600, you wrote: >After what seems like days of suffering, I've given up on figuring what >the problem is with egcs+gas+PE linker. Here's the problem in a nut-shell: >egcs back-end generates named sections that are marked ".linkonce >discard", and if you have lots of templates, you get the same benefit as >on an ELF system. the PE linker gathers up all the named sections and >picks one for you. Unfortunately, it looks as if there is a nasty bug >where the linker is not doing it's job, and you get multiply-defined >symbols. I first thought it was the code generator, then it was gas, and >now I believe the problem lies in ld. > >To avoid this hassle, I've reverted the code generation to the old days; >the pro is that it works, and the con is that you can't deal with >templates like you can on an ELF system. For all currently working code >under gcc, this shouldn't be a problem. Most of my old code that works >with gcc-2.7.2 also works, and so does octave-2.0.9 (modified to support >new template syntax changes in CD2). > >Hopefully those more familiar with BFD/gas/ld can shed some light on >this. > >The new updated binary snapshot should be up shortly (URL after sig). > >Regards, >Mumit -- khan AT xraylith DOT wisc DOT edu >http://www.xraylith.wisc.edu/~khan/ >http://www.xraylith.wisc.edu/~khan/software/gnu-win32 > >- >For help on using this list (especially unsubscribing), send a message to >"gnu-win32-request AT cygnus DOT com" with one line of text: "help". > (jeffdbREMOVETHIS AT netzone DOT com) delete REMOVETHIS from the above to reply Mikey - For help on using this list (especially unsubscribing), send a message to "gnu-win32-request AT cygnus DOT com" with one line of text: "help".