.gnu.linkonce COFF support

.gnu.linkonce COFF support

[Mark E.]

Hello Ian and the list,
Some questions about possibilities for DJGPP COFF. Would enabling 
.gnu.linkonce.* for DJGPP COFF improve template support much over 
what weak symbols do already? This would require enabling the long 
section name feature (> 8 characters) , but it can be turned on by one 
line.

And from what I can gather from reading the source, existing object 
files would still be readable by the new binutils binaries produced (ld, 
objdump, etc). without this feature. Did I read correctly? And also new 
object files using just short names produced with the long section 
name feature would be readable by old binutils binaries?

Mark
--- 
Mark Elbrecht, snowball3@bigfoot.com
http://snowball.frogspace.net/

Re: .gnu.linkonce COFF support

[Ian Lance Taylor]

   From: "Mark E." <snowball3@bigfoot.com>
   Date: Tue, 13 Jul 1999 17:41:22 -0400

   Some questions about possibilities for DJGPP COFF. Would enabling 
   .gnu.linkonce.* for DJGPP COFF improve template support much over 
   what weak symbols do already?

My understanding is that it would.  At least when using ELF, current
g++ generates the required template functions whenever it needs them.
Thus in a final link you may wind up with many copies of a particular
template function.  The .gnu.linkonce.* sections are used to throw
away the unnecessary duplicates, resulting in a smaller program.

However, there are other schemes g++ can use to generate template
functions.  They all have various disadvantages.  The disadvantage of
the ELF scheme is that g++ compiles a bunch of duplicate code you
don't need, so compilations take longer, and also your object files
are bigger; the advantage is that you don't have to think about it,
and your final executable is no larger than it has to be.

I'm not up on all the details.  I don't know which scheme is used for
DJGPP.

   This would require enabling the long 
   section name feature (> 8 characters) , but it can be turned on by one 
   line.

As I recall DJGPP doesn't use BFD_ASSEMBLER, so I think you'll
probably need at least two lines: one in BFD and one in gas.

   And from what I can gather from reading the source, existing object 
   files would still be readable by the new binutils binaries produced (ld, 
   objdump, etc). without this feature. Did I read correctly? And also new 
   object files using just short names produced with the long section 
   name feature would be readable by old binutils binaries?

Yes, this should all be correct.  In fact, old binutils binaries
should be able to read new object files with long names, but the long
section names will look funny.

Ian

Re: .gnu.linkonce COFF support

[DJ Delorie]

> Some questions about possibilities for DJGPP COFF. Would enabling 
> .gnu.linkonce.* for DJGPP COFF improve template support much over 
> what weak symbols do already? This would require enabling the long 
> section name feature (> 8 characters) , but it can be turned on by one 
> line.

The "long section name feature" is a remnant from PE's specs, and
binutils doesn't implement it properly.  The right way is to use a
specially designated symbol (usually the function name's symbol) as
the unique id, not the section name.  I would discourage adding broken
support to DJGPP when it needs to be fixed for PE anyway.  If you want
to go this route, figure out how to do it the right way (the MS PE
way) so that we won't have to jump through hoops later when the PE
support is fixed.

There are some additional symbol *types* defined for PE that DJGPP
could use to help with templatest, but I've never studied the C++
problems long enough to be sure.

Re: .gnu.linkonce COFF support

[Ian Lance Taylor]

   Date: Tue, 13 Jul 1999 21:45:49 -0400 (EDT)
   From: DJ Delorie <dj@delorie.com>

   > Some questions about possibilities for DJGPP COFF. Would enabling 
   > .gnu.linkonce.* for DJGPP COFF improve template support much over 
   > what weak symbols do already? This would require enabling the long 
   > section name feature (> 8 characters) , but it can be turned on by one 
   > line.

   The "long section name feature" is a remnant from PE's specs, and
   binutils doesn't implement it properly.  The right way is to use a
   specially designated symbol (usually the function name's symbol) as
   the unique id, not the section name.  I would discourage adding broken
   support to DJGPP when it needs to be fixed for PE anyway.  If you want
   to go this route, figure out how to do it the right way (the MS PE
   way) so that we won't have to jump through hoops later when the PE
   support is fixed.

I'm not sure this is quite right.

The COMDAT section support in the binutils is wrong, and it does work
the way you say.

The long section name support is different and unrelated.  As far as I
know, the binutils support long section names as they are used and
generated by the Microsoft tools.

I took Mark's question to be literally about .gnu.linkonce.*, as in
the GNU extension to ELF, which was perhaps an error.  It's true that
I wouldn't recommend using PE style COMDAT sections right now, since
that work will change.

Ian

Re: .gnu.linkonce COFF support

[Mark E.]

> The "long section name feature" is a remnant from PE's specs, and
> binutils doesn't implement it properly.  The right way is to use a

Ian addressed your concern, so I'll skip it. BTW, if I'm going to enable 
long section names, I'll let djgpp-workers know beforehand. I don't the 
change, if it even happens, should affect the debuggers since the bytes 
in the sections with long section names will be put into the .text and 
.data sections by the linker script anyway (once modifed of course).
 
> There are some additional symbol *types* defined for PE that DJGPP
> could use to help with templatest, but I've never studied the C++
> problems long enough to be sure.
> 

Thanks, I'll take a look.

--- 
Mark Elbrecht, snowball3@bigfoot.com
http://snowball.frogspace.net/

Re: .gnu.linkonce COFF support

[DJ Delorie]

> The long section name support is different and unrelated.  As far as I
> know, the binutils support long section names as they are used and
> generated by the Microsoft tools.

There are two ways of implementing long section names in COFF: the gnu
way, and the PE way.  We got that wrong too.  The GNU way is to store
the name in the string table.  The PE way is to use multiple auxents.
As far as *using* long section names for various features, that's OK
with me, except for the COMDAT thing.

Not, of course, that I care about what MS's format says, since djgpp
is independent of PE, but I'd hate to see us do the work twice if we
can do it once for both platforms.

Re: .gnu.linkonce COFF support

[Ian Lance Taylor]

   Date: Wed, 14 Jul 1999 07:32:19 -0400 (EDT)
   From: DJ Delorie <dj@delorie.com>


   > The long section name support is different and unrelated.  As far as I
   > know, the binutils support long section names as they are used and
   > generated by the Microsoft tools.

   There are two ways of implementing long section names in COFF: the gnu
   way, and the PE way.  We got that wrong too.  The GNU way is to store
   the name in the string table.  The PE way is to use multiple auxents.
   As far as *using* long section names for various features, that's OK
   with me, except for the COMDAT thing.

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.

Ian

Re: .gnu.linkonce COFF support

[Mark E.]

> 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/