This is the mail archive of the binutils@sourceware.cygnus.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: DJGPP and alignment


   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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]