From: lfm AT pgroup DOT com (Larry Meadows) Subject: Re: ld and microsoft libraries 2 May 1998 03:41:15 -0700 Message-ID: <199805011706.KAA20208.cygnus.gnu-win32@pacific.pgroup.com> References: <199805011630 DOT MAA09024 AT tweedledumb DOT cygnus DOT com> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit To: ian AT cygnus DOT com Cc: gnu-win32 AT cygnus DOT com > I was not aware of that feature of comdat sections. I thought comdat > sections mainly worked to eliminate duplicate sections, which the GNU > linker does support. Does the MS linker really pull specific sections > out of an object file based on symbol references? I don't see any > reference to that in the PE documentation, although that doesn't mean > it doesn't happen. That would imply that the MS linker can treat an > object file like an archive. That is exactly what happens. If you're familiar with VMS, a similar thing went (goes?) on there. There's a magic switch to the compilers that puts each function into its own text section (and, I suppose, data section if that function has static data). Any ideas on implementation? Also, unfortunately, I can't send you the MS libraries. But I could send you a .obj that shows the issues. > The associative comdat seems fairly straightforward to implement. > Make a second pass over the sections immediately after the pass using > sec_already_linked, and for each associative section check whether the > appropriate other section is being included. I don't see why you have > to worry about symbols in this case. You're right, symbols aren't important in this case. Only tricky part would be determining if the other section had been included -- this is done by section number in the .o file, which would have to be somehow represented in the internal section. I'll admit that I'm not terribly familiar nor comfortable with the BFD. lfm - 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".