From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Mark E." To: Ian Lance Taylor , snowball3@bigfoot.com, binutils@sourceware.cygnus.com Subject: Re: .gnu.linkonce COFF support Date: Wed, 14 Jul 1999 17:04:00 -0000 Message-id: <199907142109.VAA219354@out2.ibm.net> References: <199907141132.HAA22001@indy.delorie.com> <19990714175746.12585.qmail@daffy.airs.com> X-SW-Source: 1999-q3/msg00206.html > I do have some vague memory of that now. The code implemented by the > binutils is the approach described in the Microsoft PE documentation-- > I just checked again. But perhaps the Microsoft tools actually do > something different. My understanding comes from coffcode.h and coffgen.c in bfd. COFF long section names are enabled by defining COFF_LONG_SECTION_NAMES. This feature is implemented by storing the long names in the string table and storing a pointer to the table entry in the section's name field. I assume this would have to done in a way compatible with Microsoft since its used with PE COMDAT. There also seems to be a long filename feature enabled by COFF_LONG_FILE_NAMES which does much the same thing for the .file directive. PE targets define COFF_LONG_SECTION_NAMES because COMDAT sections need long section names. PE COMDAT seems to do more than just be a overly complicated way of emulating .gnu.linkonce for g++, but isn't currently implemented in binutils (as DJ notes). So it seems PE COMDAT is dependant on having long names, but long names aren't dependant on PE COMDAT. Therefore, DJGPP should be able to use long section names in implementing .gnu.linkonce support without tangling with PE COMDAT? Mark --- Mark Elbrecht, snowball3@bigfoot.com http://snowball.frogspace.net/