This is the mail archive of the
binutils@sourceware.cygnus.com
mailing list for the binutils project.
Re: .gnu.linkonce COFF support
- To: Ian Lance Taylor <ian@zembu.com>, snowball3@bigfoot.com, binutils@sourceware.cygnus.com
- Subject: Re: .gnu.linkonce COFF support
- From: "Mark E." <snowball3@bigfoot.com>
- Date: Wed, 14 Jul 1999 17:09:36 -0400
- References: <199907141132.HAA22001@indy.delorie.com> (message from DJ Delorie on Wed, 14 Jul 1999 07:32:19 -0400 (EDT))
> 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/