From mboxrd@z Thu Jan  1 00:00:00 1970
From: Ian Lance Taylor <ian@zembu.com>
To: snowball3@bigfoot.com
Cc: binutils@sourceware.cygnus.com, djgpp-workers@delorie.com
Subject: Re: DJGPP and alignment
Date: Wed, 21 Jul 1999 17:35:00 -0000
Message-id: <19990722003428.12362.qmail@daffy.airs.com>
References: <199907211607.QAA38452@out1.ibm.net> <199907220030.AAA09334@out5.ibm.net>
X-SW-Source: 1999-q3/msg00286.html

   From: "Mark E." <snowball3@bigfoot.com>
   Date: Wed, 21 Jul 1999 20:30:51 -0400

   > I fear you're getting yourself into trouble, since there's no
   > way to change the section alignment in coff. 

   Since the documentation is silent on this, what does 
   COFF_DEFAULT_SECTION_ALIGNMENT_POWER do then? My tests 
   show it does increase the size of the object files and executables 
   accordingly.

Richard means that COFF can not change the alignment on a section by
section basis (i960 COFF is an exception).  The alignment is fixed to
a specific value: COFF_DEFAULT_SECTION_ALIGNMENT_POWER.

   > If you do any sort of collect-sections-to-make-data kinds of
   > things like .ctors or .dtors, that'll break.  Do you know that
   > you're using collect2 to construct constructor lists?

   I'm not 100% sure, but I don't think so. The linker script groups them 
   together in the .data section and surrounds them with special symbols 
   (djgpp_first_ctor, etc.) defined in the script.

Yes, but *(.ctors) in the linker will align each .ctors section in an
input file to COFF_DEFAULT_SECTION_ALIGNMENT_POWER, which will put
unsightly zero values in the .ctors section in the output file.

Or it would if .ctors and .dtors were not specially handled in
coff_new_section_hook in coffcode.h.  So you're OK on constructors and
destructors if you do indeed use the section names .ctors and .dtors.

Ian