Sender: donn AT delorie DOT com
Message-ID: <37968ECF.E35A6119@verinet.com>
Date: Wed, 21 Jul 1999 21:23:59 -0600
From: Donn Terry <donn AT verinet DOT com>
X-Mailer: Mozilla 4.07 [en] (X11; I; Linux 2.0.36 i586)
MIME-Version: 1.0
To: Ian Lance Taylor <ian AT zembu DOT com>
CC: snowball3 AT bigfoot DOT com, binutils AT sourceware DOT cygnus DOT com,
        djgpp-workers AT delorie DOT com
Subject: Re: DJGPP and alignment
References: <199907211607 DOT QAA38452 AT out1 DOT ibm DOT net>; from Mark E. on Wed, Jul 21, 1999 at 12:07:18PM -0400 <199907220030 DOT AAA09334 AT out5 DOT ibm DOT net> <19990722003428 DOT 12362 DOT qmail AT daffy DOT airs DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
Reply-To: djgpp-workers AT delorie DOT com

Ian Lance Taylor wrote:

>    From: "Mark E." <snowball3 AT bigfoot DOT 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.

Except for the special cases discussed below.  (And... MS PE format does
have a way to encode the alignment of each section contribution in the
file header, but it's not currently honored by ld.)

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

To answer Mark's question to me in this context: it's defintely
coff_new_section_hook.
The existing (approved) code handles .stabs,  .ctors and .dtors.  With the
proposed
change (which I otherwise think is a good idea) .idata (and .pdata, if you
care) need
to be added to the list.  In the case of .ctors and .dtors, I think Ian is
right to characterize
the zeros as "unsightly".  For  .idata and .pdata, they're catastrophic.

In the fullness of time, I will submit changes that handle this (if this
doesn't beat me
to it) but it will be a while before I get things into a package that's
going to get approved.

Donn