Re: DJGPP and alignment

[Donn Terry <donn@verinet.com>]

Ian Lance Taylor wrote:

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

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